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

[Matthew Kerwin <[e-mail]>]

On 23 May 2014 15:26, Mike Bishop <[e-mail]> 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
supported.



>  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
legal.​


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
  http://matthew.kerwin.net.au/