W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: New Version Notification for draft-bishop-http2-extension-frames-01.txt

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Fri, 23 May 2014 19:15:26 +1000
Message-ID: <CACweHNCmY8BfH7kxKUFxT5yqJ2RGwotg-wrtc567DiE=GUjong@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: James M Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, Roberto Peon <grmocg@gmail.com>
On 23 May 2014 15:26, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

>  My intermediate version said all extensions were hop-by-hop and
> negotiated; end-to-end was added in response to James’ feedback.  The
> requirement that extensions define how, if at all, they get translated to
> back-end links that do/do not support the extension was the only end-to-end
> version I had prior to that change.  I’m still ambivalent about that, but
> if there’s a use-case, I’m not opposed.
​I'd be interested to know what James's extensions are.

>  If we do allow end-to-end, though, I think they *have* to be silently
> discardable -- because, as Matthew observes, there’s no chance to
> negotiate.  If I can’t know what you’ll recognize, I can’t avoid sending
> you something you won’t.
​Yeah, I agree, if they are allowed.​

>  The only end-to-end extension I’ve currently thought of is the one that
> was a sample in the previous version, Server Hint.  (Forget if that’s what
> we actually called it.)  Basically, rather than actively pushing, it’s a
> server-driven “You’ll want to check that these resources are in your cache
> and current.” that works for when you suspect a client may already have a
> resource, or the resource is hosted on another server.  There’s no harm if
> an intermediary observes it going by and also freshens its cache, but the
> intended recipient is the user agent.  But like Push, if the UA just drops
> it, it will discover that it wants the resource a little later.
​Sounds to me like a HTTP header. In fact, it sounds like something in the
Cache-Control family. Just because HTTP/2 does server push doesn't mean
sending unsolicited information (call it hints, whatever) is limited ​to
HTTP/2. HTTP/1.1 could definitely benefit from such an extension, if it was

>  As for hardening, Gabriel and I discussed that some.  Let’s say we’re
> just talking about hop-by-hop:
>    - If we say you can’t send *any* extension frames until you’ve seen
>    the other party’s EXTENSIONS, then you can’t use any in your first
>    request.  That may be acceptable, but seems sub-optimal.
​​Could you move the EXTENSIONS frame to a settings parameter? A single
settings frame could contain multiple such parameters, and settings are
already mandatorily sent as soon as the connection is established, and
they're acked.​

>    - If we say you MUST NOT send even informative extensions once you’ve
>    seen the other party’s EXTENSIONS and you know they haven’t requested it,
>    how do you know when to
>    ​
>    ​
>    enforce the MUST NOT?
​Start at time 0. I don't see why it should be a problem for an extension
frame that may have caused a protocol error earlier to suddenly become

Now we need an ACK for this too, or every connection begins ​with
> SETTINGS-EXTENSIONS-PING to simulate one.  Plus, that means the server has
> to maintain two different states -- one in which it permits unknown frames,
> and one in which it doesn’t.
Another reason to use a setting?

  Matthew Kerwin
Received on Friday, 23 May 2014 09:15:58 UTC

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