Re: HTTP2 Expression of Interest : Squid

Support on "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."

BTW, we have been running HTTP over UDP (scheme as HTTPP) successfully.

Best regards
  Tom

On Sun, Jul 15, 2012 at 6:19 PM, tom <zs68j2ee@gmail.com> wrote:

>
> On Sun, Jul 15, 2012 at 6:02 PM, Amos Jeffries <squid3@treenet.co.nz>wrote:
>
>> 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
>>
>>
>>
>