Feature: HTTP/1.1 support

  • Goal: HTTP/1.1 (RFC 2616) compliance

  • Status: 90% compliant and counting.

  • Version: 3.2

Contents

  1. Feature: HTTP/1.1 support
    1. Summary
      1. Checklist
    2. Forwarding path
    3. Request/Reply Upgrade path
    4. Transfer encoding
    5. Related minor tasks
    6. Range Requests
    7. Older notes

Summary

Squid-3.2 claims HTTP/1.1 support. Squid v3.1 claims HTTP/1.1 support but only in sent requests (from Squid to servers). Earlier Squid versions do not claim HTTP/1.1 support by default because they cannot fully handle Expect:100-continue, 1xx responses, and/or chunked messages.

Co-Advisor tests no longer detect RFC 2616 MUST-level violations in Squid trunk when it comes to requirements unrelated to caching. Many caching-related requirements are still violated. The "compliance percentage" in the project header is essentially a marketing gimmick (i.e., meaningless or misleading but technically correct information). We are actively working on fixing all known violations detected by Co-Advisor.

Checklist

Current Squid compliance with RFC 2616 MUST-level requirements: HTTP-1.1-Checklist_2012-09-01.ods

The linked document contains the results of automated Co-Advisor HTTP/1.1 compliance tests for several Squid versions. Each test consists of almost 700 individual test cases, targeting various MUSTs in RFC 2616. For each Squid3 version, we executed several tests. The tests were identical from HTTP point of view. If a given test case showed different results during those tests, the exact test case outcome could not be determined. Such outcomes are marked with a letter 'U'. All other markings correspond to stable results. Some test cases fail due to lack of an HTTP/1.1 feature support in Squid, incompatibility with the test suite, a test suite bug, or other reasons. Such test cases are marked with question marks. The remaining test case outcomes are successes and violations. Only successful outcomes count towards the "test cases passed" percentage.

The tests are on vanilla Squid with no special alterations made during build. The 2.7 test appears to have been done with the configurable HTTP/1.1 advertisement to Servers turned on.

Forwarding path

The forwarding path needs to be cleaned up to better separate HTTP messages and actual content, allowing for proper forwarding of 1xx responses.

This is likely to touch the store API as today all messages go via the store, even if just an interim 1xx response.

  • Temporary step for Squid-3.1: catch expect-100 on requests and send back the correct error to cause a retry when client sends Expect-100 in a request. Until such time as Squid can support expect-100.

UPDATE: 1xx forwarding has been implemented in Squid-3.2. The forwarding path still needs further work to make this efficient.

Request/Reply Upgrade path

RFC2616 requires that we upgrade to our highest supported version. This has been found problematic with certain broken clients and servers.

  • NP: ICY protocol seems to be the main breakage. So ICY support has been implemented natively from Squid-3.1 to fix this.

  • NP: Sharepoint and several other MS products break with authentication loops when different HTTP/1.x versions are advertised on server and client side (as seen with Squid-3.1).

We may require a generic upgrade_http option which takes a version number, allow/deny, and a list of ACLs. Plus two new ACLs to test for the request HTTP version and reply HTTP version.

  • NP: The Measurement Factory have patches for these options. They will be merged to Squid only if real need is demonstrated.

Requirements to consider:

  • ACL controls to halt the upgrade at a certain level (ie permit upgrade 0.9 to 1.0, but not 0.9->1.1).

  • separate upgrade 0.9 -> 1.0 from 1.0->1.1 tasks.

  • reply pathway stepping stones similar to handle reply downgrade in mirror to the upgrades made.

Transfer encoding

HTTP/1.1 requires support for chunked encoding in both parsers and composers. This applies to both responses and requests.

Both Squid-3 and Squid-2 contain at least response chunked decoding. The chunked encoding portion is available from Squid-3.2 on all traffic except CONNECT requests.

Additionally work should also be done in the following

  • Cleanups to comply better with the RFCs. (see the Checklist)
  • Implement cache invalidation requirements.
    • If-None-Match header creation on revalidation requests
    • Support correct caching and revalidation of no-cache on responses

Range Requests

Squid is unable to store range requests and is currently limited to converting the request into a full request or passing it on unaltered to the backend server.

  • We need to implement storage to allow for partial range storage.
  • There are also a handful of bugs in the existing range handling which need to be resolved.

Older notes

Copied from Features/Other:

Some thought will need to be put into the following area:

  • HTTP entity types

Discussion: What is meant by this? Please expand and move up.

CategoryFeature

Features/HTTP11 (last edited 2013-02-09 09:08:01 by Amos Jeffries)