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

Re: [svndiff1] Accept-Encoding in mod_dav_svn

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2005-11-21 00:35:38 CET

On Sun, 2005-11-20 at 23:14 +0000, Malcolm Rowe wrote:
> Hi Dan,
> I had a quick look at the mod_dav_svn changes you made for svndiff1.
> I'm a little worried that one of the ways we're changing it doesn't
> exactly follow the HTTP spec. To clarify, I'm not worried particularly
> about supporting a theoretical client that doesn't use libsvn_ra_dav,
> more about possible interaction with HTTP proxy servers, if we do
> something that they're not expecting.
> From what I can see (and please correct me if I'm wrong), we're going
> to continue sending svndiff0 responses by default, but if the client
> requests svndiff1 by including it in the Accept-Encoding header, we'll
> send that instead.


> The most obvious thing that's missing is that we don't appear to be
> sending anything in the response (like 'Content-Encoding') that indicates
> which format we've actually sent. Now presumably that's because we can
> identify the format by inspection, but it's still odd.
Well, we've always done this, AFAIK. We don't current say the
content-encoding is svndiff.

> [ RFC2616 ยง14.11: If the content-coding of an entity is not "identity",
> then the response MUST include a Content-Encoding entity-header that
> lists the non-identity content-coding(s) used. ]
> (Actually, more importantly, doesn't this interfere with the use of
> things like mod_deflate, which already use Accept-Encoding: gzip?)

In fact, neon already will send multiple Accept-Encoding headers (and
process them), and the server processes them okay, merging as necessary.

> I'm also not sure that the content-encoding is the right place for this
> decision. Arguably, I suppose, 'svndiff' and 'svndiff1' are different
> encodings of the same representation. But if that's true, what's the
> representation using the identity transformation?


> (and per the quoted
> section of the RFC, we should already be using 'Content-Encoding: svndiff'
> if that was the case).

True, but we don't :)

> Unless 'svndiff' is the representation format, and 'svndiff1' an
> additional content-encoding method: that almost works - apart from the
> interaction with mod_deflate, of course.

No, we use svndiff to say what we send now, and svndiff1 for the

> Anyway, I wondered if, instead of using Accept-Encoding, it would
> be possible to use the Accept header for the purpose we want? (which
> really looks like picking one of two equivalent representations).

I asked dlr
> How does Neon react if we return a different Content-Type than text/xml?
> (It should be okay, I would have thought: application/x-svndiff+xml
> and application/x-svndiff1+xml are perfectly fine XML MIME types,
> per RFC3023).

> Finally, a very very small nit: according to the spec, quality values
> of zero indicate that the UA cannot deal with a particular content type
> or encoding. Therefore, the header
> Accept-Encoding: svndiff1;q=0.0
> should be processed accordingly, disallowing the svndiff1 format (and
> so falling back to svndiff0). Currently, we don't do that. [Likewise,
> Accept-Encoding: svndiff;q=0.0 should, strictly speaking, indicates a
> client that can't accept the svndiff0 encoding. In theory, we should
> then send svndiff1, but that's pretty obscure.]
That's fine.

Honestly, I don't care what we do in mod_dav_svn. I only bothered to
add svndiff1 support there for completeness. I have zero interest in
DAV, as it is complicated and slow :)

> Regards,
> Malcolm

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 21 00:36:24 2005

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