Re: RFC 7838 ALTSVC Frame

> On 14 Apr 2016, at 09:59, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> I can't speak to consensus, that will come with time, but physics
> dictates the frame has to be sent after the server receives the
> request (otherwise the server is advertising an alternative for an
> origin it can't guess about).  I would also hope that the stream isn't
> closed when the frame is sent, but I can't rely on physics to support
> that unfortunately.

So that suggests that the maximal set of stream states in which ALTSVC can be *sent* is open, reserved (local), half-closed (remote), half-closed (local), and closed().

Two follow-on questions then:

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?)
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).

Cory