On 10/26/2014 3:21 AM, Branko Čibej wrote:
> On 26.10.2014 05:49, Sean Leonard wrote:
>> On 10/25/2014 5:59 PM, Branko Čibej wrote:
>>> On 25.10.2014 20:53, Sean Leonard wrote:
>>>> It appears that the matter was not fully resolved. svn:charset seems
>>>> to enjoy de-facto use.
>>> If anyone is using svn:charset, they're violating our rules. The svn:
>>> namespace is reserved for property names defined by Subversion, and
>>> we've not defined that name. So ... using that name is likely to cause
>>> problems at some point.
>> Ok. So I guess the issue of how Subversion encodes a particular
>> character set/character encoding is still "live"?
> Well, Subversion doesn't "encode" anything; but for the purpose of
> serving content straight from the repository through an HTTP server, the
> established way to define the character set is to add the tag to the
> svn:mime-type property, e.g.:
> svn propset svn:mime-type 'text/plain; charset=UTF-8' file...
Actually I have a different proposal: what if the property name is the
parameter, prefixed with "svn:mime-type:", and the property value is the
UTF-8 encoded parameter value?
svn:mime-type:versions "nroff 2013"
This would be easier for Subversion clients to manage and parse. It
matches all of the semantics.
However, if there is already established code that encodes or decodes
parameters, then encoding everything into svn:mime-type is not
> That will be exposed to the browser in the Content-Type header, and the
> Subversion client, which uses svn:mime-type for its own purposes, will
> ignore any content type parameters (that is, anything after the semicolon).
I looked through the source code and found one place where the
svn:mime-type property is parsed: svn_mime_type_is_binary (in
libsvn_subr/validate.c). It looks for the ; delimiter. Looks like
svn_mime_type_is_binary is quite popular in the source.
Are there other places where this property is parsed or interpreted?
> The restriction here is that Subversion restricts the value of the
> svn:mime-type property to be in the ASCII; which, incidentally, is
> required by RFC2045 (see: https://www.ietf.org/rfc/rfc2045.txt section 5.1).
OK. How does Subversion restrict the value to US-ASCII?
Received on 2014-10-26 16:08:50 CET