Re: [RFC] Using LZ4 compression by default

Paul Hammant <paul_at_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
Received on 2017-08-04 15:57:44 CEST