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

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