Re: HTTP router point-of-view concerns

On 11/07/2013 10:52 a.m., Christian Parpart wrote:
> Hey guys,
>
> I am just new to this list and I've just recently started working 
> through the HTTP/2 draft and all the blog articles found about.
> That being said, I myself have also very concerns others have noticed 
> as well, and would like to deeply show my intention to help standing 
> aside :)
>
> I am the implementor of one of the many HTTP servers that's being used 
> in production, and one major feature is HTTP routing / load balancing,
> and I would really love to implement an HTTP/1.1 successor that is (to 
> be) officially labeled HTTP/2[.0].
>
> However, as a varnish [1] and a BSD [2] guy also raised there hands 
> on, is the lag of easy extraction of envelop information of an HTTP 
> request message, such as method, path, but most certainly the host.
>
> Please forgive me if this is already on-topic somewhere hidden, 
> however, I would really highly encourage you to consider
> adding some dedicated frame type for this kind of envelope information.
>
> With that in mind, one might say that an HTTP/2 stream is not 
> initiated by a HEADERS frame but the ENVELOPE frame that contains the 
> actual
> uncompressed and unmystified but compact information about this 
> request message.
>
> One humble proposal might indeed be:
>
> type: (something unassigned)
> flags: bit 1 = END_STREAM /* this HTTP message is complete with just 
> these envelope frame, e.g. a simple GET, and no need for user-agent 
> etc. */
> id: unique stream ID, semantics like any other stream ID
> body: a key/value table of the envelope data
>
> ENVELOPE FRAME DATA:
>
> The envelope data table is a simple table of key/value pairs where the 
> key is an 8bit value identifying the entry
> and a variable length value that is interpreted depending on the key. 
> The list of provided envelope fields ends
> as the end of the envelope frame has been reached. that means, an 
> envelope must always fit into a single (first) frame.
>
> ENVELOPE KEY/VALUE FIELDS:
>
>   * :scheme => uint8: 0x01
>       o http => uint8: 0x01
>       o https => uint8: 0x02
>       o custom => same as in method (if this is distinction is really
>         demanded)
>   * :method => uint8: 0x02
>       o GET => uint8: 0x01
>       o POST => uint8: 0x02
>       o PUT => uint8: 0x03
>       o DELETE => uint8:0x04
>       o custom => uint8: 0xFF, followed by one uint8 encoding the size
>         of the following bytes declaring the plaintext method value,
>         e.g. "PROPFIND"
>   * :path => uint8: 0x03, uint16 length in network byte order,
>     followed by $length octects declaring the path's value.
>   * :host => uint8: 0x04, uint16: length in network byte order,
>     $length octets declaring the host's value.
>   * :route => uint8: 0x05, uint8: length, $length octets that declare
>     this value. (field is only specified if known, thus previousely
>     announced by the remote server or this frame is part of a response
>     and we are to announce a routing identifier)
>   * :status => uint8: 0x06, uint16: code in network byte order  /* if
>     HTTP/2 considers starting response streams the same way */
>
> This is the exact information an HTTP client (scheme,method,path,host) 
> or server (status) MUST currently sent as part of the (first) HEADERS 
> frame.
> So the change I propose is, to extract this information from the 
> HEADERS frame and put it into its own frame that also initiates the 
> stream implicitly.
>
> Having this in mind, it is a pleasure to implement HTTP routers 
> because those now don't have to decode the full HEADERS frames but 
> just decode the ENVELOPE frame and pass any continued frame to the 
> directed next-hop server.

Sadly the compression draft as written is completely incompatible with 
this type of load balancing. It operates a *stateful* compressor, such 
that every single HEADERS frame being received has to be decoded in 
order to re-encode using a separate connection-specific stateful 
compressor on the next-hop connections. This is mandatory for the 
compressed frames regardless of whether the ENVELOPE header is used to 
provide uncompressed details.
  The best load balancers can do under the current compression draft is 
to avoid complex re-encoding by emiting only Literal header 
representations and skipping all the traffic optimizations compression 
offers. Which converts them into near perfect DDoS 
bandwidth-amplification sources.

The sad state of affairs is that the *only* type of middleware which 
benefits from the proposed HTTP/2 is those which performs transparent 
interception and passive monitoring/recording of users traffic (ie the 
worst kind). Anything which starts modifying or manipulating (ie doing 
something useful for the ISP or CDN) MUST implement a full 
compressor/decompressor pair in order to keep the HTTP/2 statefulness in 
order.

Amos

Received on Thursday, 11 July 2013 02:54:09 UTC