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.
Yes.
>
> 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?)
No.
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?
svndiff.
> (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
version.
>
>
> 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