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.
Max.
---------------------------------------------------------------------
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