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

Re: [Issue 3979] chunked transfer encoding not always supported

From: Philip Martin <philip_at_codematters.co.uk>
Date: Fri, 05 Aug 2011 14:11:34 +0100

gstein_at_tigris.org writes:

> The short answer is that serf communicates using HTTP/1.1 (defined by
> RFC 2616, back in June 1999).

And it's not implemented everywhere and we have to take that into

> With some work, we could support HTTP/1.0. The biggest problem here
> would be needing to pre- compute the size of the request (and use
> Content-Length: rather than chunked requests), which could result in
> using a temporary file on disk in some cases. Where we know the
> request is size-bounded, then we could use a memory buffer. To get
> really spiffy, the new "memory buffer, then spill to disk"
> functionality (developed for issue 3888) could be used to avoid the
> disk in some (many?) request scenarios.
> (that buffer/spill code is destined for libsvn_subr in the trunk line
> of development, for use on the server-side, per a request from
> cmpilato)

So what is the benefit to users of 1.7 of chunked encoding? There is a
very obvious drawback in that serf fails to work through some proxies
and the solution in 1.7 is "use neon".

Received on 2011-08-05 15:12:12 CEST

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.