Paul Hammant <p...@hammant.org> writes: > Wouldn't the svn client just speculatively specify a HTTP "Accepts" header > with requests up to the server? You'd be able to do back/forwards > compatibility with that, and not have to change any other wire spec ?
I think that this is close to how things currently work, and what makes the compatibility possible. However, it's still up to the client to decide, what kind of compressed data (LZ4 / zlib or uncompressed ) it wants more, so the client advertises this preference via the ;q= quality parameter. Perhaps, for historical reasons, we don't use separate "Accept" and "Accept-Encoding" headers. In other words, currently, instead of something like this Accept-Encoding: gzip Accept: application/vnd.svn-svndiff;format=2;q=0.9, application/vnd.svn-svndiff;format=1;q=0.8, ... a client sends Accept-Encoding: gzip,svndiff2;q=0.9,svndiff1;q=0.8, ... ("gzip" is there as the server might be configured to send uncompressed deltas, but gzip the whole response.) Another thing to consider is that Accept-Encoding headers only handle the part where the server sends data to the client. In order for the client to properly prepare the request body that the server can interpret, there's an additional layer of capability negotiation that happens during the first OPTIONS request. Regards, Evgeny Kotkov