[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ra_dav compression question

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2003-06-24 00:50:40 CEST

--On Monday, June 23, 2003 3:12 PM -0700 Chris Hecker <checker@d6.com> wrote:

> 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

What SetInputFilter docs are you reading? I'm not aware of any current web
browser supports sending compressed request bodies.

> 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?

Having support for compressed request bodies and compressed response bodies
are separate. Making an assumption that the two are always linked would be a
very bad thing to do. Plus, the server might only allow compressed request
bodies based on the request-uri.

> 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)

> 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.

> 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 :).

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.

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

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:51:33 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.