Marc Elsen wrote:
>
> Charles Bruneteau wrote:
> > I face a "subtle" issue with the way squid (2.2S5 & 2.5S1) handles tcp
> > connection timeout with the CONNECT method:
> > - 'GET ...' to a down webserver produces a 504 status code
> > - 'CONNECT ...' to a down webserver doesn't: once the tcp timeout occured squid
> > simply closes the tcp session (FIN) with the client.
> > Is there a reason ?
>
> Don't know, but I think that 5xx, 4xx, etc. are http status codes only
> and are not related to https connections.
I guess that's not so easy: 403, 407 etc. are related to every methods.
For instance squid do ask for proxy authentication with a 407 status code.
> > With Internet Explorer, proxy authentication and a proxypac listing several
> > proxies for redundancy it generates some issues: IE understand this session
> > ending as a signal to use another proxy (as if the proxy was down).
> > Some other proxies would generate a 504 or 500 error (NetApp for instance).
>
> Hm, I would assume that proxy selection is unrelated to a http or
> https site being down.
I agree: it should not.
> I would not like my browser to change proxy, if one site either
> http or https is down.
>
> Or, proxy selection algorythm, is unrelated to any states
> encountered with http or https connectivity for a specific proxy.
Squid simply shuts the TCP session, without any HTTP notice.
>From the HTTP client point of view that's not a great partner.
Nevertheless IE is a bit more nasty here: even if some other simultaneous
sessions are ok with the same proxy, the first https requests encountering such
a timeout will cause the use of a new proxy.
I didn't find any information about the behaviour proxies should have in such
case.
Regards
C.
Received on Tue Dec 24 2002 - 08:09:57 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:12:12 MST