[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [feature] Log HTTP header for autoversioning

From: Michael Sweet <mike_at_easysw.com>
Date: 2005-01-13 21:16:54 CET

Max Bowsher wrote:
> ...
>> Since Content-Type is already a standard HTTP header and maps
>> directly to the svn:mime-type property, I would say that it would
>> make sense to set that property as well.
> Interesting. Could this prove annoying in some circumstances, though?
> Suppose you PUT to a file which has a specific content type from some
> client that doesn't know, and sends a generic "text/plain". The desired
> content type would be changed.
> Do HTTP PUT clients exist? Do they send Content-type by default?

I just checked RFC 2616, and unfortunately the entity headers are
a SHOULD, not a MUST, so Content-Type is optional.

I would say that for PUT requests, just set the property when the
file is created, otherwise keep the existing svn:mime-type property
value and require the client to use PROPPATCH to change it.

We could also filter out common defaults for Content-Type -
text/plain which may be the default for some clients and is
essentially the default for SVN, and application/octet-stream
which is often used for unknown files and auto-typing.

I don't want this to become a major undertaking/headache, but the
thought of updating/adding files to a SVN repo with simple PUT
requests is intriging - I have a photo app which supports HTTP PUT
uploads; until now I have just PUT to the filesystem, but if I
can do it with Subversion then I can better manage this process... :)

Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 13 21:18:53 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.