Serf doesn't work with non HTTP/1.1 proxies (squid/perlbal...)

[GoogleCodeExporter]

This issue was reported by 'durin42' on #svn-dev yesterday.

What steps will reproduce the problem?
Using svn from trunk:
$ svn co http://code.djangoproject.com/svn/django/trunk /tmp/wc

Output: svn will return a 400 Bad Request error

What is the expected output? What do you see instead?
The 400 Bad Request error is returned on the first PROPFIND request to the
remote server. 

When looking at the exact response with wireshark, we get this error message:
"perlbal: Can't pipeline to HTTP/1.0"

The code fragment in perlbal that reports this error refers to the missing
Content-Length field in the request header:
http://code.sixapart.com/trac/perlbal/changeset/577

If my reading of the comment in that fragment is correct, perlbal requires
the Content-Length field when the client tries to pipeline multiple
requests in order to avoid flooding attacks.

Original issue reported on code.google.com by lieven.govaerts@gmail.com on 22 Sep 2007 at 8:31

[GoogleCodeExporter]

I had similar and potentially related problems with 
http://divmod.org/svn/Divmod/trunk/Pyflakes recently. I 
didn't have time to debug it much, but switching to neon fixed things.

Original comment by durin42 on 30 Apr 2008 at 3:13

[GoogleCodeExporter]

Updated the summary.

Serf requires the server/proxy to support chunked encoding, which not all 
proxies do. 

Until the rest of the world starts supporting HTTP/1.1, we might want to 
implement
HTTP/1.0 fallback support. 

Original comment by lieven.govaerts@gmail.com on 13 Oct 2008 at 11:26

• Changed title: Serf doesn't work with non HTTP/1.1 proxies (squid/perlbal...)

[GoogleCodeExporter]

It's not just a matter of proxies supporting HTTP/1.1

Chunked requests to a proxy create a major dilemma for the proxy.  A proxy 
can't 
send a chunked request upstream unless it KNOWS the next hop is HTTP/1.1.  It 
can't 
know this unless it keeps a cache of versions for servers it talks to.

I can't see how serf doesn't know how much data it's sending, so there should 
be no 
reason why it can't just set Content-Length instead of using chunking.  This 
will 
then work with HTTP/1.1 and HTTP/1.0, plus a lot of proxies that advertise 
support 
for HTTP/1.1 but which don't support chunked requests.

There's no need to call this "fallback to HTTP/1.0"  Content-Length is the 
normal 
method for indicating length in 1.1 requests as well.

Original comment by adr...@qbik.com on 23 Jun 2009 at 11:55

[GoogleCodeExporter]

Patch posted to serf-dev which allows serf to send C-L encoded bodies in most 
cases.  Still not sure whether it should be applied...

http://groups.google.com/group/serf-dev/browse_thread/thread/daf20b361627334d#

Original comment by justin.e...@gmail.com on 25 May 2011 at 1:16

[GoogleCodeExporter]

The original issue was reported in the issue list of Subversion here:
http://subversion.tigris.org/issues/show_bug.cgi?id=3979

With the new API serf_bucket_request_set_CL added by Justin svn has now been 
fixed as follows:
- for the first request on a connection, calculate and set content length. Serf 
will add the content-length header, and specify HTTP/1.1 as supported version.
- if the server returns HTTP/1.1 in the response, svn will stop setting content 
length, so serf will use chunked-encoding for all following requests.
- if the server returned HTTP/1.0, svn will calculate content length for all 
requests (temporary streaming request bodies to disc until they are constructed 
completely).

Reusing gstein's quote from RFC 2145, section 2:

"One consequence of these rules is that an HTTP/1.1 message sent to an
   HTTP/1.0 recipient (or a recipient whose version is unknown) MUST be
   constructed so that it remains a valid HTTP/1.0 message when all
   headers not defined in the HTTP/1.0 specification [1] are removed." 

For me this means that we need to fix this in serf itself, so that all 
applications automatically do the right thing.

Original comment by lieven.govaerts@gmail.com on 5 Nov 2012 at 1:58