>Neon could be modified to send compressed request bodies. But, that's
>more difficult because there is no 'handshake' to ensure that the server
>can handle compressed request bodies. With responses, the client sends
>the 'Accept-Encoding: gzip' in the request, so there is a 'handshake' to
>ensure that both sides can support deflate. So, compressing request
>bodies isn't a realistic expectation to support with HTTP.
Sure, but how do the mysterious other DAV clients mentioned near the
SetInputFilter docs handle this? I'd assume that on the first reply from
the server it would send an Accept-Encoding: gzip back, and from that point
on neon would compress on that connection. This assumes the connections
are kept alive so that the second+ requests on the same connection can be
compressed. I assume svn always does a small request at the start anyway
to get a clue about the current situation, so there'd only be a tiny bit of
uncompressed data going to the server before the compression started. Does
neon keep the connection alive and keep state about it so that this would
be possible?
Hmm, from looking into this more, it looks like any Content-Encoding: gzip
response from apache is Connection: close (even if you requested
keep-alive), which not only means you can't do the keepalive thing I
mentioned above on a single connection, but also that _every_ request
answered with compressed data closes the connection on apache2 (I assume
because that's how apache tells you the compressed data is done since
Content-Length is the uncompressed size, even though if the receiver was
smart the uncompressed size would be enough info). For https this really
sucks, because it means the SSL connection is renegotiated on every
request, which has got to be really slow for updating a huge repository,
although I haven't timed it. Am I missing something here (hopefully), or
is this totally broken, performance-wise for https?
Also, the server doesn't seem to send back Accept-Encoding: gzip on
replies, so you probably just have to try a Content-Encoding: gzip request
and see if it doesn't error back to decide if you can do it.
It seems like this is fairly important to either fix or mention in the
manual near the place where "wire compression" is claimed when using
apache, since it is not bidirectional like it's implied. And, the
performance tradeoff of sending Accept-Encoding: gzip and dealing with the
zillion reconnects versus not sending it and having a keepalive connection
would be interesting to look into (assuming I'm right about that, and by
someone with more http experience than me :).
>Using ra_svn with ssh tunneling with compression enabled would do both
>ways as it blindly does compression on all data.
Right, but it seems like you'd want to keep the ra_dav path as feature-ful
as the ra_svn path, since it has a lot of other advantages as claimed in
the manual (including not having to give people shell accounts to give them
repository access, which is huge).
Thanks!
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 24 00:14:09 2003