- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Thu, 14 Apr 2016 10:38:28 +0100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP WG <ietf-http-wg@w3.org>
Received on Thursday, 14 April 2016 09:38:58 UTC
> 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
Received on Thursday, 14 April 2016 09:38:58 UTC