Re: [squid-users] 2nd recv delay on GET

From: David Rosenbloom <david@dont-contact.us>
Date: Fri, 4 Apr 2003 14:43:49 -0500 (Eastern Standard Time)

Ah - Wording that last msg brought the unique condition to mind: the
initial http request with authentication.

I think it may be that the 1st 0-return (all data already sent) recv() on
the newly established
persistent connection times out, whereas subsequent calls' 0-return
recv()s are immediate. I will verify.

- davidr

On Fri, 4 Apr 2003, David Rosenbloom wrote:

> Many thanks.
>
> What I don't grasp is why in other passes through the same code with the
> same negotiated connection, the 2nd recv() simply gets an immediate 0
> return from squid, rather than the recv() not returning until timeout as
> in this case. I will investigate further.
>
> - davidr
>
>
>
> On Fri, 4 Apr 2003, Henrik Nordstrom wrote:
>
> > In both of the requests seen in clisqi.enc there is no second packet to
> > be expected. All of the response (headers + data) is contained in the
> > first packet.
> >
> > And as you have negotiated the use of persistent connections, the
> > connection will stay around until it times out, waiting for you to send
> > another request on the same connection.
> >
> > If you at this stage attempts to read more from the connection then
> > recv() will appear to hang until Squid gives up waiting for you to send
> > another request and closes the connection.
> >
> > Regards
> > Henrik
> >
> > tor 2003-04-03 klockan 18.54 skrev David Rosenbloom:
> > > Many thanks for peeking. I have no doubt this is a problem on our end,
> > > either with the client programming or the squid conf. Note that this only
> > > happens when squid is set to Basic auth, not when it is set to no auth;
> > > there is no delay in the no auth case. As I mentioned, there is no delay
> > > in the auth case with socks (dante), but in that case both the http and
> > > https calls are prefaced by a socks connect, whereas the http connect only
> > > prefaces the https calls in the squid case, the http calls going through
> > > with the auth creds added to the headers..
> > >
> > > The behavior: client starts up, logs in over https (without noticable
> > > delay), heartbeats periodically (over http); when user requests search,
> > > client issues GET (GroupListing.jsp - frame 12 of clisqi.enc), which squid
> > > immediately sends to web server, receiving returned data (frame 23, 24 of
> > > sqiserv.enc). But then the client hangs from frame 14 to 16 (clisqi.enc)
> > > for almost 30 sec. (Linger is set to 30 sec, but removing it didn't solve
> > > the prob). I assume this is the 2nd recv(), although it may coincide with
> > > a new heartbeat (frame 18).
> > >
> > > Oddly, the heartbeat return is parsed in the same code that the
> > > GroupListing return is, yet it does not exhibit this behavior, nor do the
> > > other http calls from the client. Hence my assumption that the prob is
> > > on our end.
> > >
> > > Any ideas much appreciated.
> > >
> > > Again, many thanks,
> > > - davidr
> > >
> > >
> > >
> > > On 3 Apr 2003, Henrik Nordstrom wrote:
> > >
> > > > This is not symptoms I recognize.
> > > >
> > > > Please make a packet dump of the traffic both between your client and
> > > > Squid and between Squid and the web server when processing this request.
> > > >
> > > > Regards
> > > > Henrik
> > > >
> > > >
> > > > tis 2003-04-01 klockan 21.24 skrev David Rosenbloom:
> > > > > With the default squid config with Basic auth enabled, I am experiencing
> > > > > the following:
> > > > >
> > > > > In my app which sends HTTP requests, a loop processes recv()'s until a 0
> > > > > or error return. With direct connect and via a socks proxy (dante), this
> > > > > works fine, but with squid, the 2nd recv (rather, all recvs after the
> > > > > initial) takes a _long_ time before returning. The data is (eventually)
> > > > > received complete, but the waits are a problem.
> > > > >
> > > > > The headers passed in with the call are
> > > > > Pragma: no-cache
> > > > > Proxy-Connection: Keep-Alive
> > > > > Proxy-Authorization: Basic" : [creds]
> > > > >
> > > > > The HTTPS calls which use CONNECT do not exhibit this problem.
> > > > >
> > > > > Is there something - header, socket option - on the calling end that can
> > > > > address this? On the squid config end?
> > > > >
> > > > > thanks,
> > > > > - davidr
> > > > >
> > > > --
> > > > Free Squid-users support provided by Henrik Nordström <hno@squid-cache.org>
> > > > PayPal donations welcome if you consider my Free Squid support helpful.
> > > > https://www.paypal.com/xclick/business=hno%40squid-cache.org&cn=Comment
> > > >
> > > > If you need commercial Squid support or cost effective Squid and
> > > > firewall appliances please refer to MARA Systems AB, Sweden
> > > > http://www.marasystems.com/, info@marasystems.com
> > > >
> > > >
> > --
> > Henrik Nordstrom <hno@squid-cache.org>
> > MARA Systems AB, Sweden
> >
> >
>
Received on Fri Apr 04 2003 - 12:44:03 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:40 MST