[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: Max Bowsher <maxb_at_ukf.net>
Date: 2005-01-14 01:30:07 CET

Michael Sweet wrote:
> 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... :)

This complexity here is getting to the point where doing this properly would
require a few new mod_dav_svn config directives - to control the precise
response to Content-type on an autoversioning PUT.

At this point, I feel I have to defer to someone more knowledgable about the
innards of mod_dav_svn regarding whether this feature's balance of increased
complexity to usefulness is worthwhile overall.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 14 01:31:34 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.