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

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:32:15 MST