Subject: RFC 7838 ALTSVC Frame

From: Cory Benfield <[email-masked]>
Date: Thu, 14 Apr 2016 09:46:27 +0100

All,

I’m implementing support in hyper-h2 for the ALTSVC frame as specified in RFC 7838. However, a detailed read of RFC 7838 does not appear to define what stream state the ALTSVC frame may be sent in. This is in contrast to the frames in RFC 7540 which explicitly list in which stream states they are acceptable.

The closest I can see is an allusion in the text that says "Receiving an ALTSVC frame is semantically equivalent to receiving an Alt-Svc header field”, which suggests that the correct answer may be the open and half-closed remote states, but it’s still unclear. Can I send ALTSVC on closed streams? On idle streams? What about half-closed (local) streams? Can they be sent at any time?

Can I get some clarification from this WG about what the consensus is here? I know that nghttp2 has implemented support already, so in the absence of any further information I’ll take the now-traditional route of “just do what nghttp2 does”, but I’d like a bit more clarity than that!

Thanks

Cory

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Apr 2016 18:59:29 +1000

On 14 April 2016 at 18:46, Cory Benfield <[email-masked]> wrote:
> Can I get some clarification from this WG about what the consensus is here?

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.

---

From: Cory Benfield <[email-masked]>
Date: Thu, 14 Apr 2016 10:38:28 +0100

> On 14 Apr 2016, at 09:59, Martin Thomson <[email-masked]> wrote:
> 

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Apr 2016 19:44:26 +1000

> 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, j…

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.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 15 Apr 2016 01:02:23 +0900

Hi,

On Thu, Apr 14, 2016 at 6:44 PM, Martin Thomson <[email-masked]>
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?)
>
> > 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).
>
​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