Re: RFC 7838 ALTSVC Frame

On 14 April 2016 at 19:38, Cory Benfield <cory@lukasa.co.uk> wrote:
> 1. Do we have any reason to want to restrict that further? (e.g. ALTSVC in half-closed(local) feels a bit weird, but might be ok I guess?)

I assume that you mean sending in half-closed (local).  Well the main
reason for not sending after the response has been delivered is that
the client has probably lost all state.  In fact, I would suggest that
it probably isn't a good idea to send ALTSVC once you have completed
the HEADERS block for the response, because by then most clients move
to a completely different mode.

> 2. Do we feel comfortable having implementations just silently ignore ALTSVC in the other states? That’s in line with what we do for ALTSVC on stream 0 (which, if the origin field is not present, just gets silently ignored), but feels a bit annoying to me (silent failure is a bit sad).

Well, the cat is out of the bag now.  We didn't restrict the states
and now we have implicit permission to send any time.  Ignoring is
fine (since ignoring ALTSVC is always fine), so I guess we can only
recommend when is best to send to maximize the chance that clients
actually see the frame.

Received on Thursday, 14 April 2016 09:44:57 UTC