HTTP2 Expression of Interest : Squid

[Amos Jeffries <[e-mail]>]

As the current Squid proxy maintainer this is my expression of interest 
in HTTP/2.0. It is made as an individual submission with a mind for the 
Squid Project and user community needs but due to the collaborative 
nature of the Squid Project does not represent the Project as a whole.


The Squid Project implements a general-use HTTP proxy with capabilities 
including but not limited to; caching, content adaptation, content 
generation and assembly, content filtering, access control, HTTP 
routing, HTTP and HTTPS interception, HTTP traffic quality of service 
flow controls, and traffic optimization.

The development of improved HTTP protocol in all forms is of high 
interest to the Squid Project. Fast and efficient proxy operations are 
of paramount interest for the Squid user community.


HTTP/1.1 issues

The Squid Project developers are aware of numerous issues surrounding 
syntax parsing and processing which complex handling limits the 
throughput capacity of proxy installations. These syntax parsing 
inefficiencies are directly impacting on the user community goal of high 
performance.

The Squid Project community has often expressed feedback complaints 
which after investigation turn out to be based on HTTP connection 
capabilities, largely inherited from HTTP/1.0 default connections-close 
behaviours but which also remain within HTTP/1.1 due to dynamic content 
and limitations with pipelining failure recovery. Improved connection 
multiplexing and pipelining is seen as a desirable behaviour for better 
performance by many within the Squid community.

HTTP/1 contains a few signalling issues which have on occasion led to 
inefficient designs being implemented to avoid problems. The 1XX status 
feature of HTTP/1 goes some way towards this. However a more efficient 
signalling feature is needed to raise the overall efficiency of HTTP.

HTTP/1 is implicitly limited to TCP-like stream transports. There have 
been user community proposals for extension to transmit HTTP over other 
protocols. These are echoed by a number of RFC proposals for alternative 
protocols to transfer the same resources over other datagram and 
security-oriented transfer protocols. The Squid user community includes 
groups with particular interests in such additional protocol underlays 
for HTTP and seeing any future deployments more flexible than the 
current infrastructure.


HTTP/2 interest

The Squid proxy implementation is driven by community contributions, 
with guidance from a group of core developers maintaining Project focus 
and consistency. As such I cannot speak for certain about whether Squid 
Project will (or not) implement any particular proposal in the future.


draft-mbelshe-httpbis-spdy-00
-----------------------------

The SPDY proposal appears to offer an alternative to HTTPS, but is 
tightly tied to TCP and TLS infrastructure. As such it cannot meet the 
transport portability and message transparency requirements several 
groups within the Squid user community have as mandatory features for 
both operational and legal reasons. Nor can it efficiently support the 
interception and transformation needs of a large portion of the community.

There have been community requests for implementation of the SPDY 
protocol within Squid. However as yet none of the community have been 
willing to produce an implementation. Also, due to lack of 
implementation for SPDY connection to proxies from Browsers the public 
implementation focus of SPDY within Squid community has been limited to 
discussions of whether SPDY could be intercepted and translated back 
into HTTP/1, and for implementing a SPDY gateway with any efficiency.

There are also a number of semantic feature extensions above and beyond 
HTTP/1 included in this specification. This may or may not be an issue 
for implementation, but it seems early to spring new semantics

My view is that SPDY layering should be separated and the non-HTTP layer 
considered as an alternative transport for HTTP similar to TCP, UDP, 
STCP, CoAP and HTCP which all seek to relay HTTP messages. Only the HTTP 
specific syntax and framing improvements should be considered by the WG 
as input to HTTP/2 specifications.


draft-montenegro-httpbis-speed-mobility-02
------------------------------------------

This proposal lacks a measure of support for HTTP/1 features. A gateway 
definition for translation of HTTP/1 features into the mobility frames 
is sadly lacking.

Since this proposal uses WebSocket framing; there have been no comments 
or requests from the Squid user community or developers towards 
implementing WebSockets in Squid. The developer projects to my knowledge 
are limited to intercepting WebSockets and translating as much as 
possible into HTTP/1 traffic.

My view is that the introductory sections of this draft should be 
considered as important requirements input to the WG designs.


draft-tarreau-httpbis-network-friendly-00
-----------------------------------------

This proposal has been designed with the SPDY improvements and many of 
the problems identified by the Squid community and developers in mind. 
It contains mandatory functionality which are seen by the Squid user 
community as beneficial for high-performance proxying; multiplexing and 
pipelining, flow control (implied, not stated specifically), and 
efficient HTTP-specific header compression. While leaving optional all 
features which are beneficial only to specific groups within the Squid 
user community and HTTP environment as a whole; security, 
authentication, data integrity, push/pull, and sessions.

As co-author of this proposal I have been working on an implementation 
for use within the Squid code and use by other projects.

My view on this is naturally biased, that the WG should take this draft 
as an outline on which to adapt the framing specifics and integrate the 
HTTP/2 requirements.


Overall Perspecitive:

I look forward to working with the HTTPbis working group on combining 
the designs from all these proposals into a final HTTP/2 specification. 
As specified currently none of the proposals are suitable for large 
scale implementation, but all have some small measure of support from 
within the user community.



Amos Jeffries
Squid Project