[squid-users] Re: [Off-topic] generic HTTP proxy questions - not Squid related

Sounds like your browser have a bit of a problem with redirects and
persistent connections, or actually the ISA server (perhaps in
combination with the HTTP server in question). In HTTP/1.1 the server
SHOULD signal that the connection is to be closed by including a
"Connection: close" header in the reply. But on the other hand,
clients MUST be prepared to retransmit requests sent over persistent
connections in case the server (or proxy) chooses to tear down the
connection.. so neither IE 5.01 or your ISA server is behaving
stricly correctly here, but the error in IE 5.01 is worse than the
ISA error.

Yes, proxies (and servers) are allowed to respond with HTTP/1.1 even
if the client request was HTTP/1.0, and proxies are in theory allowed
to upgrade HTTP/1.0 replies received from origin servers to HTTP/1.1
but must then be prepared to perform proper downgrades to HTTP/1.0
when forwarding any additional requests.

My guess on what happens here is that ISA is upgrading the reply to
HTTP/1.1 but for some reason forgets to keep the connection
peristently open (the default in HTTP/1.1), immediately aborting the
connection after sending the 302 reply and thereby triggering a bug
in the request reforwarding in IE 5.01, making IE fail to resend the
request when detecting that the connection got aborted..

Keep-alive and Host are two very common extensions to HTTP/1.0,
appeared long before the first HTTP/1.1 draft was even started. Both
are supported by all browsers on the marked, and nearly all HTTP
servers and proxies. Just as HTTP/1.1 is, HTTP/1.0 is extensible
allowing for these extensions while still being fully compliant. The
original documentation of these extensions can be found at Netscape.

What you can try as a workaround is to install a Squid proxy
inbetween the browser and the ISA server and configure Squid to
disable the use of client-side persistent connections.

In squid.conf:

  client_persistent_connections off

Note however that if the ISA server is using HTTP NTLM authentication
then this won't work as NTLM authentication cannot be proxied.
Standard HTTP Basic authentication (plaintext authentication in MS
terminology IIRC) can be proxied just fine.

Regards
Henrik

On Sunday 12 May 2002 21:44, Filip Sneppe wrote:
> Hi Henrik,
>
> I know you from your Squid work and netfilter contributions. What I
> am about to ask you has nothing to do with Squid whatsoever. I just
> have some generic HTTP proxy questions based on some observations I
> noticed between IE5.01 users and the Microsoft ISA server Proxy on
> one of our clients' networks.
>
> I already asked about this in the more appropriate forums, but did
> not receive any answers. Since you are an HTTP Proxy authority, I
> am now turning to you.
>
> If you can't be bothered to answer it, I can understand that.
>
> My question is simple: who is not following RFCs or any other
> specification:
>
> Scenario 1:
>
> if you surf to http://www.vlaanderen.be, you will notive that you
> get redirected twice before hitting the real content of the site. I
> am observing that IE5.01 surfers are not able to follow the second
> redirect.
>
> This is what a network trace reveals:
>
> - client and proxy perform TCP handshake
> - client requests a page via HTTP GET.
> - authentication is checked against Active Directory, client has to
> retry the HTTP GET ...
> - proxy fetches page from internet site
> - it's a HTTP 302 message in HTTP/1.0. Headers are:
>
> HTTP/1.0 302 Moved Temporarily
> Date: Wed, 08 May 2002 11:10:02 CEST
> Server: Redirector
> Location:
> http://portal.vlaanderen.be:80/http://portal-svr1-web.portal.vlaand
>eren.be:8080/login?gw=portal.vlaanderen.be&domain=portal.vlaanderen.
>be Content-Length: 246
> Content-Type: text/html
>
> - The 302 message is passed to the client, in HTTP/1.1, like this:
>
> HTTP/1.1 302 Moved Temporarily
> Via: 1.0 S6
> Content-Length: 246
> Date: Wed, 08 May 2002 11:10:02 CEST
> Location:
> http://portal.vlaanderen.be:80/http://portal-svr1-web.portal.vlaand
>eren.be:8080/login?gw=portal.vlaanderen.be&domain=portal.vlaanderen.
>be Content-Type: text/html
> Server: Redirector
>
> - The proxy then sends a TCP ACK+FIN packet to the client to close
> the connection, this is then acknowledged by the client
>
> - the client then sends an HTTP GET (1.1) for the redirected site,
> over the same connection that has just received a FIN+ACK from the
> server.
>
> - the proxy responds with a TCP RST.
>
> - the client displays an error message in the browser and makes no
> further attempts to fetch the redirected site...
>
> Scenario 2:
>
> basically the same as scenario 1, except that in the browser
> settings, the browser is forced to use HTTP/1.0 for proxy requests.
> The bahavior is identical to scenario 1. The only difference is
> that, even though the client requests are HTTP/1.0, the proxy
> replies are HTTP/1.1. My additional question is: is a proxy allowed
> to give HTTP/1.1 responses when a client uses HTTP/1.0 ? Note that
> the client does add "Connection: Keep-alive" and "Host: " headers
> to the HTTP/1.0 GET, which IMHO is not strictly HTTP/1.0
> compliant...
>
> IMHO, the client (Internet Explorer and/or Windows 2000) is to
> blame for this behavior, as it essentially reuses a tcp connection
> that is closing for a new HTTP command, and the proxy TCP stack
> just rejects it. But I am just wondering if the Proxy has some part
> in the blame.
>
> Regards,
> Filip

-- 
MARA Systems AB, Giving you basic free Squid support
Your source of advanced web reverse proxying solutions
http://www.marasystems.com/products/