2011/5/17 Justin Erenkrantz <justin_at_erenkrantz.com>:
> On Mon, May 16, 2011 at 10:48 PM, Konstantin Kolinko
> <knst.kolinko_at_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.)
Received on 2011-05-17 01:13:47 CEST