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 <[EMAIL PROTECTED]> > > > 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/, [EMAIL PROTECTED] > > > > > > > -- > Henrik Nordstrom <[EMAIL PROTECTED]> > MARA Systems AB, Sweden > >
