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
Attachment:
signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel
