Thanks Amos,
Should this affect performance of squid for clients using HTTP1.1? For instance:
* will number of connections at any one time increase to squid & so
we'll need to increase squid file descriptors?
* will the increase in connections affect the performance/capacity of
squid?
* will it affect the network performance?
I presume the user experience will benefit, with reduced loading time for pages
with many images/etc. but in general once a browser has downloaded all the
images/etc., will it then close the connection immediately, or wait 2 minutes
to close?
Thanks and regards,
Justin
-----Original Message-----
From: Amos Jeffries [mailto:[email protected]]
Sent: Friday, March 23, 2012 12:37 PM
To: [email protected]
Subject: Re: [squid-users] Accessing Squid by telnet - differences in behavior?
On 23/03/2012 5:22 p.m., Justin Lawler wrote:
> Hi,
>
> Comparing a legacy instance of squid (squid 3.0.15) with the latest (3.1.19),
> and we noticed some differences. Wondering what the change was.
>
> When we telnet into the port& do a "Get http://www.gmail.com http/1.1" - on
> legacy squid, once it returns the content it closes the connection
> immediately. On the newest version of squid it waits 2 minutes before closing
> the connection.
>
> Is this anything to be worried about? Can it be configured?
Squid 3.0 is HTTP/1.0-only.
Squid 3.1 is almost HTTP/1.1 compliant. It attempts to use HTTP/1.1 features
whenever possible, but still advertises itself as 1.0 to prevent the client
software depending on the few 1.1-only features which are still missing.
One of the supported HTTP/1.1 features is persistent connections being
assumed on by default. Your telnet request specified that you were a
HTTP/1.1 compliant client and failed to specify "Connection:close", therefore
Squid keeps the connection open waiting for another request.
Not something to worry about. But if you are in the habit of writing scripts
that send "HTTP/1.1", it may be worthwhile checking that they are actully
HTTP/1.1 compliant in even small ways like this.
Amos
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
