Subject: Editorial: ALTSVC HTTP/2 Frame.

From: Bence Béky <[email-masked]>
Date: Thu, 8 Jan 2015 10:52:42 -0500

Hi,

I see that the ALTSVC HTTP/2 Frame format has changed from draft-04 to
draft-05.  If I understand correctly, now the HTTP/2 frame cannot
contain an Origin field.  This makes the following two paragraphs in
https://tools.ietf.org/id/draft-ietf-httpbis-alt-svc-05.html#rfc.section.4
moot:

"An ALTSVC frame from a server to a client on stream 0 indicates that
the conveyed alternative service is associated with the origin
contained in the Origin field of the frame. An association with an
origin that the client does not consider authoritative for the current
connection MUST be ignored."

"An ALTSVC frame on a client-initiated stream containing non-empty
"Origin" information is invalid and MUST be ignored. Likewise, an
ALTSVC frame on stream 0 with empty (length 0) "Origin" information is
invalid and MUST be ignored."

If this is the case, then they should be removed and replaced by the text
"An ALTSVC frame MUST not have a stream identifier of 0.".

Please let me know if my understanding is correct.  In this case, I
would be glad to prepare the proposed change on GitHub.  Thank you.

Best wishes,

Bence

---

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Jan 2015 17:22:40 +0100

On 2015-01-08 16:52, Bence Béky wrote:
> ...

It can contain what the header field contains, and that allows 
specifying the authority (uri-host and port).

Am I missing something?

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Jan 2015 08:46:10 -0800

On 8 January 2015 at 08:22, Julian Reschke <[email-masked]> wrote:
> It can contain what the header field contains, and that allows specifying
> the authority (uri-host and port).
>
> Am I missing something?

It would seem so.

The header field doesn't contain origin information because that is
derived from the request.  The header field says: "for requests to
*the origin of this request*, please send here: list of service
endpoint tuples"; when the frame is sent on stream 0, it lacks that
context.

I suggest that you define the frame as length (sadly, 255 bytes isn't
long enough to hold the longest conceivable origin string) plus origin
plus the remainder being exactly the same as the Alt-Svc header field.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Jan 2015 18:04:13 +0100

> plus the remainder being exactly the same as the Alt-Svc header field.

I see. Thanks for the explanation.

An alternative would be to put it into an "o" parameter (to be ignored 
in the header field). Or resurrect draft-reschke-http-jfv and switch to 
JSON...

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Jan 2015 09:12:46 -0800

On 8 January 2015 at 09:04, Julian Reschke <[email-masked]> wrote:
> An alternative would be to put it into an "o" parameter (to be ignored in
> the header field). Or resurrect draft-reschke-http-jfv and switch to JSON...

Either works for me.  I think that -jfv might be a good candidate for
HTTP/next discussion though.

---

From: Erik Nygren <[email-masked]>
Date: Thu, 8 Jan 2015 14:13:43 -0500

What Martin suggests here makes sense to me.  Good catch, Bence.

---

From: Bence Béky <[email-masked]>
Date: Wed, 14 Jan 2015 15:24:27 -0500

Created a commit at
https://github.com/httpwg/http-extensions/pull/39/commits.  Martin, is
this what you had in mind?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Jan 2015 14:07:34 -0800

> this what you had in mind?

Yes, though I think we need a 16-bit length to cover the corner cases
(origins with perversely long domain names will go over).

---

From: Michael Sweet <[email-masked]>
Date: Wed, 14 Jan 2015 20:52:44 -0500

Haven't looked at the changed text, but the maximum length of a FQDN is 255 octets...

> On Jan 14, 2015, at 5:07 PM, Martin Thomson <[email-masked]> wrote:
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Jan 2015 19:37:34 -0800

> Haven't looked at the changed text, but the maximum length of a FQDN is 255 octets...

Indeed it is.  But origin includes <scheme>://<fqdn>[:<port>].  A
9-bit length would suffice...

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Jan 2015 07:24:37 +0100

> 9-bit length would suffice...

Stop it. Let's not mix binary and text in the same frame. I'll add a 
"origin" parameter to the header field syntax.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Jan 2015 19:33:52 +1100

On 15 Jan 2015, at 5:24 pm, Julian Reschke <[email-masked]> wrote:
> Stop it. Let's not mix binary and text in the same frame. I'll add a "origin" parameter to the header field syntax.

I'm personally -0.5 about that; putting the origin in the header field syntax when it isn't useful in the header field's semantics is bound to cause confusion. 

My .02 - decide on a generous bit length and we're done this one.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Jan 2015 09:39:54 +0100

> My .02 - decide on a generous bit length and we're done this one.

Having two different approaches in the same frame (binary and text) 
makes me shudder...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Jan 2015 19:42:06 +1100

> On 28 Jan 2015, at 7:39 pm, Julian Reschke <[email-masked]> wrote:
> 
> Having two different approaches in the same frame (binary and text) makes me shudder...

Well, the frame *is* binary; nothing's going to change that. And, the content *is* text -- likewise. The question is whether there's one text field or two...

Cheers,