Subject: ORIGIN frame feedback

From: Lucas Pardue <[email-masked]>
Date: Sun, 16 Jul 2017 12:21:03 +0000

Hi,

Dusting off my ORIGIN frame implementation, I'm unsure in a few areas. Below are some questions/suggestions, I'm happy to prepare some PRs if there is agreement:

Repetition of fields
I naively assumed the ORIGIN frame was very similar to the ALTSVC frame, I missed out on the repetition element. I think it would help to improve upon diagram in section 2.1, first coin a term for the Origin-Len:ASCII-Origin pair (it is loosely referred to as set, which is easily confused with Origin Set), for this email I'll use the term Origin-Entry. Section 2.1 would be changed to contain two clearly labelled diagrams: one shall show the fields comprising an Origin-Entry, the other shall show the ORIGIN frame payload as an OPTIONAL sequence of Origin-Entries, with cardinality of 0-*. 0 indicates an empty ORIGIN frame, which is implied by the text in Appendix B - "inform the client that the connection is only to be used for the SNI-based origin, by sending an empty ORIGIN frame.".

Expectations for Origin Set size
If my interpretation of the specification is correct, the Origin Set is currently unbounded. While the size of an individual H2 frame is bounded and negotiated, the Origin set can seemingly be added to ad nauseam. Even in the default size case, for a short ASCII-Origin<http://www.dirk-loss.de/short-domains.htm> such as http://dk, if might be possible to create an Origin set with ~1500 entries. I like the fact that ORIGIN frame extension doesn't need any negotiation, so perhaps some guidance for client-side implementations would help e.g. be aware of the Origin Set size and be prepared to close the connection if you're getting unhappy.

Non-normative processing algorithm
Is this reflective of current ORIGIN frame fields? The terminology seems slightly askew as each Origin is comprised of two fields and I'm wondering if it got outdated. Using the term Origin-Entry could help here.

Regards
Lucas

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 16 Jul 2017 15:05:00 +0200

Thanks, Lucas! Some responses below.

> On 16 Jul 2017, at 2:21 pm, Lucas Pardue <[email-masked]> wrote:
> 
> Hi,
>  
> Dusting off my ORIGIN frame implementation, I’m unsure in a few areas. Below are some questions/suggestions, I’m happy to prepare some PRs if there is agreement:
>  
> Repetition of fields
> I naively assumed the ORIGIN frame was very similar to the ALTSVC frame, I missed out on the repetition element. I think it would help to improve upon diagram in section 2.1, first coin a term for the Origin-Len:ASCII-Origin pair (it is loosely referred to as set, which is easily confused with Origin Set), for this email I’ll use the term Origin-Entry. Section 2.1 would be changed to contain two clearly labelled diagrams: one shall show the fields comprising an Origin-Entry, the other shall show the ORIGIN frame payload as an OPTIONAL sequence of Origin-Entries, with cardinality of 0-*. 0 indicates an empty ORIGIN frame, which is implied by the text in Appendix B - “inform the client that the connection is only to be used for the SNI-based origin, by sending an empty ORIGIN frame.”.

I agree; this has made me uncomfortable for a while. I'll take a stab at the approach you propose.

> If my interpretation of the specification is correct, the Origin Set is currently unbounded. While the size of an individual H2 frame is bounded and negotiated, the Origin set can seemingly be added to ad nauseam. Even in the default size case, for a short ASCII-Origin such as http://dk, if might be possible to create an Origin set with ~1500 entries. I like the fact that ORIGIN frame extension doesn’t need any negotiation, so perhaps some guidance for client-side implementations would help e.g. be aware of the Origin Set size and be prepared to close the connection if you’re getting unhappy.

This makes me wonder if a specific error would help servers diagnose why clients are closing connections.

> Is this reflective of current ORIGIN frame fields? The terminology seems slightly askew as each Origin is comprised of two fields and I’m wondering if it got outdated. Using the term Origin-Entry could help here.

I'll take a look.

Cheers,

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Jul 2017 14:29:05 +0200

See:
  https://github.com/httpwg/http-extensions/issues/368
  https://github.com/httpwg/http-extensions/issues/369
  https://github.com/httpwg/http-extensions/issues/370

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 18 Jul 2017 14:42:30 +0000

>   https://github.com/httpwg/http-extensions/issues/370

Thanks, is the intention to talk about these at the WG meeting?

Lucas

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------