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:squid3@xxxxxxxxxxxxx] Sent: Friday, March 23, 2012 12:37 PM To: squid-users@xxxxxxxxxxxxxxx Subject: Re: 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
