Re: Re: problems with the squid-2.5 conn
- Original Message - From: Henrik Nordstrom [EMAIL PROTECTED] To: Steven Wilton [EMAIL PROTECTED] Cc: squid-dev@squid-cache.org Sent: Wednesday, April 19, 2006 10:56 PM Subject: Sv: Re: problems with the squid-2.5 conn Yes, the Proxy-support header is only relevant when the client is using a proxy. Transparent interception is notproxying and should only behave as the webserver as that is what it is in the eye of the client. There is an 'accel' request flag you can use to determine when it is appropriate to add the header. I've made the suggested change, and it looks good now. If proxies are set, then IE will not get confused with the extra header, and if proxies are not set the extra headers are not sent. Do browsers send requests to different servers down the same TCP connection when proxies are set? If browsers do exhibit this behaviour, my patch would cause all subsequent requests on the same TCP session to have the auth, pinned and must_keepalive flags set. This is not as much of a problem when using intercept caching (as the same TCP conneciton will be going to the same web server), but I'm wondering what would happen when proxies are set. I'm also wondering if your connection pinning work addresses this issue. regards Steven
Re: Re: problems with the squid-2.5 conn
tor 2006-04-20 klockan 19:11 +0800 skrev Steven Wilton: Do browsers send requests to different servers down the same TCP connection when proxies are set? Yes, and this is an area open for exploration on what IE does when connection-oriented auth is combined with proxies... but I suppose that with your approach it will be happy no matter what. If browsers do exhibit this behaviour, my patch would cause all subsequent requests on the same TCP session to have the auth, pinned and must_keepalive flags set. Yes. Not much to be done about unfortunately. The main downside is that there might be a few requests not getting cached which otherwise would have been if the client isn't behaving and opening a new connection when visiting another site after using connection-oriented auth. A bigger problem that needs addressing is that you should somehow make sure to close the server-side connection when the client connection is gone. This to avoid excessive number of tied up server-side connections which can not be referenced any longer.. I'm also wondering if your connection pinning work addresses this issue. My approach had a very close relation between client-server connections, and barfed on the client if it did not behave. This is the area where Adrian run into stability issues.. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
