RE: [squid-users] Hotmail login issue

Henrik,

Thanks for the info, but I don't understand why this would be an
intermittent issue? How come sometimes a client can login to hotmail,
and other times it can't.
I've had a couple client point directly to the cache and so far they
haven't had any problems. They are point to port 80 and are going
through the iptables redirect rule. With this information, it would
seem that the error lies around the GRE/WCCP portion of the setup.
Could it be possible that WCCP is causing these errors?

Bryan
 
 

-----Original Message-----
From: Henrik Nordstrom [mailto:henrik@henriknordstrom.net]
Sent: March 16, 2006 8:39 AM
To: Shoebottom, Bryan
Cc: squid-users@squid-cache.org
Subject: RE: [squid-users] Hotmail login issue

tor 2006-03-16 klockan 08:02 -0500 skrev Shoebottom, Bryan:
> Henrik,
>
> If I understand properly (http://www.httpsniffer.com/http/1441.htm)
the
> issue is with squid because it doesn't know the length of the document
> requested, or it only receives half of the document and therefore
can't
> cache and relay it back to the client?
>
> I guess this is a feature of HTTP 1.1 of which squid is non-compliant.
> Am I understanding this correctly? If so, will this be fixed/added to
> squid 2.5 or 3.0? If I'm not interpreting this correctly, is there
> another workaround?

Squid is still HTTP/1.0. Even Squid-3.0 is and will be HTTP/1.0.
Transfer-Encoding is the main obstacle why Squid is still HTTP/1.0 but
there is many other small pieces as well.

If you find a server sending chunked encoding to Squid then this server
is NOT HTTP COMPLIANT. The RFC 2616 HTTP/1.1 standard has the following
to say about when to use chunked encoding:

final paragraph of

3.6 Transfer Codings:

   A server which receives an entity-body with a transfer-coding it does
   not understand SHOULD return 501 (Unimplemented), and close the
   connection. A server MUST NOT send transfer-codings to an HTTP/1.0
   client.

pay special attention to the last sentence..

Definition of "MUST NOT":

1.2 Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [34].

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST or REQUIRED level requirements for the protocols it
   implements. An implementation that satisfies all the MUST or REQUIRED
   [...]

And further clarified in RFC 2119:

2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

Regards
Henrik
Received on Thu Mar 16 2006 - 08:18:12 MST