2011/5/17 Justin Erenkrantz <jus...@erenkrantz.com>: > On Mon, May 16, 2011 at 10:48 PM, Konstantin Kolinko > <knst.koli...@gmail.com> wrote: >> HTTP/1.0 does not support keep-alive, and thus the connection will be >> closed after each request. You will need HTTP/1.1 to keep the >> connection open. > > Correct - in this particular set of circumstances, httpd is going to > either select Connection: Close or chunked response encoding. Even if > serf were to advertise that it were only 1.0, httpd would then still > choose Connection: close (as it doesn't know the response lengths). > So, since Squid doesn't know what chunked is...httpd is forced to > close the connection. > >> Maybe you are able to connect with HTTPS? > > Of course - SSL works just fine...even better with my last set of > patches over the weekend. =) > >> Quick look at the docs says that HTTP/1.1 is disabled in Squid 2.7 by >> default and its implementation "is still incomplete" [1]. Squid 3.x >> should behave better. >> >> [1] http://www.squid-cache.org/Doc/config/server_http11/ >> >> I am not a Squid admin, but just verifying my own worries about that product. > > Yes, I'm aware that squid does not adhere to any type of RFC compliance. > > The fundamental question is: is it better to have it work and perform > terribly, or have it fail and highlight to the user that they would be > better off using HTTPS or something else. > > I can support both sides of the argument...hence, my desire to get > feedback. -- justin
My personal opinion (from position of a svn user) is that HTTP/1.1 support is necessary for proper operation. Rationale behind supporting HTTP/1.0 in the library might be 1) improvement of the serf library per se 2) some simple commands might work, much like when svn repository is accessed with a web browser. svn list? svn cat? Best regards, Konstantin Kolinko (I am not subscribed to serf-dev@. It will bounce off.)
