Subject: Re: [httpwg/http-extensions] Serialization for structured headers. (#627)

From: HTTP issue updates <[email-masked]>
Date: Wed, 23 May 2018 04:13:21 -0700

(For example, can we assume any ordering in the serialization of a dictionary? :) )

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/627#issuecomment-391309882

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 23 May 2018 16:52:42 -0700

Makes sense, will do in the next round.

One hitch is that *eventually*, we want to be able to define alternative serialisations of the header field in new versions of HTTP, so we'll have to be careful in how we do this. Or just admit that there will be some residual hand-waving.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/627#issuecomment-391539905

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 23 May 2018 23:53:37 -0700

> Makes sense, will do in the next round.

Thanks, no rush. :)

> One hitch is that eventually, we want to be able to define alternative serialisations of the header field in new versions of HTTP, so we'll have to be careful in how we do this. Or just admit that there will be some residual hand-waving.

Some level of hand-waving seems fine, though I'd prefer that it be constrained to this document, and not all the documents that wish to define structured headers. If we can end up with a single algorithm, no matter how complicated, that takes a structured header object and outputs a string, I'll be happy to use it!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/627#issuecomment-391608799

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 24 May 2018 16:07:13 -0700

Nod - but the hitch is "outputs a string" -- in that future world, it might be binary...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/627#issuecomment-391892769

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 25 May 2018 04:41:33 -0700

How about "outputs a thing that might be a string, and might be binary, and might be trinary, or might be anything else I can hand to Fetch's `header list` [`set`](https://fetch.spec.whatwg.org/#concept-header-list-set) algorithm"? Fetch talks about it in terms of a https://infra.spec.whatwg.org/#byte-sequence. Would that work for you?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/627#issuecomment-392027461

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 25 May 2018 06:10:16 -0700

I love it: "A byte sequence is a sequence of bytes, represented as a space-separated sequence of bytes."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/627#issuecomment-392052900

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 25 May 2018 06:13:32 -0700

@mnot - actually, what's in a HTTP/1.1 message should also be better considered a byte sequence, not a string

@mikewest - I would prefer to have SH not to rely on FETCH in any way

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/627#issuecomment-392053750

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 25 May 2018 06:22:34 -0700

> I would prefer to have SH not to rely on FETCH in any way

Pedantic nit: Byte sequence isn't defined in Fetch, but in Infra. :)

I would like SH to define a serialization algorithm in such a way that I can explain to web browsers what they ought to do with the result. It would be unfortunate if it was difficult to integrate SH and Fetch, as that makes my goals more difficult.

I think all I'm asking for is a clearly defined serialization algorithm that returns a result that Fetch can accept as a header value. I'm happy to leave details up to y'all and @annevk to work out who depends on whom and why amongst yourselves. :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/627#issuecomment-392056017

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 25 May 2018 06:32:58 -0700

Well, that gets us back to the data model. I assume FETCH considers header field values as JavaScript strings (?), while in an HTTP/1.1 message it's really a sequence of bytes, usually restricted to values <= 127.

It's the edge case (non-ASCII) that makes this all interesting, but I believe it's a non-issue for SH.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/627#issuecomment-392059014

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 25 May 2018 06:40:58 -0700

@reschke no, byte sequences with restrictions: https://fetch.spec.whatwg.org/#concept-header. (The API does convert these back and forth from JavaScript strings, using IDL's `ByteString` primitive.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/627#issuecomment-392061197

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 25 May 2018 07:00:01 -0700

OK.

Right now we have only one serialization, so it's hard to discuss future ones.

The one that we have uses US-ASCII, which can be trivially encoded in octet sequences, and shouldn't have any issues with FETCH. So maybe we just need to write down this more clearly?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/627#issuecomment-392066914

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 25 May 2018 07:11:37 -0700

For my own understanding, the problem is that you want to create a structured header using types, but then pass that into Fetch, with Fetch only taking byte sequences, and exact byte sequences being exposed through H/1 and H/2 and probably QUIC.

Ideally you keep the types around until you hit a point where you need to serialize. That would require HTTP offering some abstraction in front of H/1, H/2 and probably QUIC that takes headers where the values can be either byte sequences or types and then serializes them as appropriate for the eventual chosen transport.

Fetch could then change its "header" primitive so values would be either byte sequences or types and pass that on to the new HTTP abstraction. And also use the H/1 / H/2 serialization for its API, which isn't typed.

As an intermediate step, structured headers could define how to obtain a byte sequence from a type. We'd continue passing byte sequences around. Then a future H/N could eagerly parse those bytes to see if it can represent them as a type instead. You'd end up with a redundant serialize/parse, but all the interfaces don't have to be changed. Implementations could optimize the serialize/parse away. And this would also allow representing byte sequences as types that weren't types to begin with, which might be beneficial.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/627#issuecomment-392070501