>What SetInputFilter docs are you reading? I'm not aware of any current
>web browser supports sending compressed request bodies.
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html#enable
It says no browsers support it but some WebDAV clients do. I couldn't find
any reference to one that did, but I didn't look for more than a few minutes.
>Plus, the server might only allow compressed request bodies based on the
>request-uri.
Right, but then I don't see how the compressed request is negotiated at all
from the bit I've looked into it. The link above implies you just send it
gzip and see what happens, but that's just my interpretation, it's not
clear from the docs.
>>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
>If you can detail why you believe this to be true, please enlighten
>me. None of my servers exhibit this behavior. Are you sure you are using
>HTTP/1.1 connections? (HTTP/1.0 defaults to Connection: close)
Yeah, it was HTTP/1.1. Based on it not happening on your servers, I looked
at it more and if I remove the User-Agent from my test header (grabbed from
MSIE 6) it keeps the connection alive, so it must be a BrowserMatch thing,
even though I can't see one that possibly matches with a nokeepalive
directive in my default httpd.conf. I'll look at it more, but that's good
to know it was my mistake and not something inherent with keepalive
there. Still, since apache won't send the Accept-Encoding: gzip back with
a response we're back to stage one on how to negotiate the gzip request.
>>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.
>You'd be trying to handle negotiation outside of the protocol. That'd be
>extremely poor behavior.
Agreed, but I don't see any way to negotiate it that's documented in my
[admittedly brief and clueless] look into this.
>In practice, the majority of the data that an SVN client would send in a
>request body would be compressed via the vdelta algorithm or be extremely
>short XML request bodies.
Except during adds, or big file changes. I agree with you for projects
with a lot of people checking in and then you update to get their changes,
but if you check in a lot of changes/adds yourself then none of your
checkins are compressed. Imagine a single person using subversion for
revision control...in that use-case, none of the file data communication is
ever compressed (beyond the "compression" in vdelta), because that single
person is doing all the changing and adding and never getting any new data
from the server, so it's all client -> server unless he updates to an older
revision.
>I don't believe there would be an extreme performance win by compressing
>the request bodies. I could be proven wrong - someone would just have to
>add compressed request bodies to neon. As long as you are talking to a
>known server that has 'SetInputFilter DEFLATE' set, it should all work
>transparently. -- justin
Yeah, I don't know if it would be a huge win either (although you'd think
on adds it would make a bit difference), I just started looking into it as
a new user and couldn't figure out how it could possibly compress
bidirectionally without a SetInputFilter. Anyway, I can probably do the
work on neon, but I still don't know how to negotiate the compression. Any
ideas on that?
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 02:11:39 2003