Re: RFC 7838 ALTSVC Frame

Hi,

On Thu, Apr 14, 2016 at 6:44 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> 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.
>
>
​I think the best way is always use stream ID = 0 and use explicit origin,
which is not affected by stream state.
If you'd like to omit origin to same several bytes, it would be good to
send ALTSVC before sending response HEADERS since client is most likely
still interested in the stream at that moment.

As for non-zero stream ID, nghttp2 ALTSVC implementation only passes
received ALTSVC to application layer if ALTSVC is received for stream which
is not closed or idle.  Otherwise, it is silently ignored, which is
permitted by the spec.

Best regards,
Tatsuhiro Tsujikawa