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

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

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

-- 
Philip