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.
[ 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?)
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).
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.
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).
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.]
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:14:54 2005