W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

Re: http2-encoded-data

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Mon, 6 Jul 2015 22:23:07 +1000
Message-ID: <CACweHNBLPgdS-UmUPZi9dwRdaA-22KkERvcM8oKxspftUuJAyQ@mail.gmail.com>
To: Stefan Eissing <stefan.eissing@greenbytes.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Thanks for the comments. My responses inline:

On 06/07/2015 6:10 PM, "Stefan Eissing" <stefan.eissing@greenbytes.de>
wrote:
>
> My comments re
http://tools.ietf.org/html/draft-kerwin-http2-encoded-data-05:
>
> Should a client announcing support be prepared to receive DATA *and*
GZIPPED_DATA frames for a single stream? There are two scenarios where I
could see that happen:
> 1. The ACCEPT_GZIPPED_DATA is received while a stream's DATA is ongoing
and the endpoint might want to switch
> 2. On a gzipped stream, small data chunks might arise that are not worth
zipping. Can a server send them as DATA?
>

Yep, that's perfectly (and intentionally) acceptable. If it's not clear
enough, I could add some words.

>
> More on the meta h2 level:
> - Allocating numbers from a small pool like frame types and error codes
gets difficult when several parties are considering extending a protocol.
Before safe numbers are allocated, experimental implementations need to
exist which may later clash. String identifiers seem to have worked better
in the past.
>
> A possible solution to this could be an X-FRAME that carries an
identifier string in its payload. A playground until business gets serious
and numbers are allocated in the protocol.
>

If you look at earlier versions, I originally made it a general 'encoded
data' frame, with a registry of codings and TE-type negotiations. That
would have reduced pressure on the frame type registry space when
introducing other encodings. (If that happened.)

I dropped it back to just gzip because it seemed like that would cover 90%
of what people would want from it, while being a whole lot simpler.

If an X-FRAME spec/draft existed I wouldn't be opposed to using it, but it
doesn't, and I personally don't see enough need to warrant writing one
myself.

>
> - Sometimes, extensions depend on each other. For an endpoint, it is much
easier/safer/robust to receive and process extension capabilities in a
package (i.e. single frame). Example: TLS extensions like SNI and ALPN have
practical dependencies, as for servers protocol support may be configured
per server. The answer to ALPN depends on the SNI. Receiving SNI+ALPN in
one protocol "packet" makes processing more robust.
>

Indeed, the -05 revision was transitional; in -06 it uses a setting. <
http://tools.ietf.org/html/draft-kerwin-http2-encoded-data-06>

>
> Cheers,
>
>   Stefan
>
Received on Monday, 6 July 2015 12:23:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:45 UTC