Re: HTTP router point-of-view concerns

[Amos Jeffries <[e-mail]>]

On 11/07/2013 3:13 p.m., Roberto Peon wrote:
> The intent was that one could negotiate a zero compression state, in 
> which case it ends up being similar to what is proposed here, I think, 
> so long as the appropriate key-value (or key) is in the static table.

It seems not to be negotiable from the recipients side. The sender can 
choose to implement a non-Substituting HEADERS frame, but the recipient 
cannot exactly require it and thus is required to implement Substitution 
state for decoding regardless of whether it is ever used. If I have 
missed something please point it out to me.

PS. not that I am arguing for or against the current aproach. It is just 
sad that the worse form of middleware gains the most benefits and 
everything else is put to a bit of trouble.

Amos

>
> -=R
>
>
> On Wed, Jul 10, 2013 at 7:53 PM, Amos Jeffries <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>
>