Subject: Re: [httpwg/http-extensions] structured-headers: Why ignore UTF-8? (#537)

From: HTTP issue updates <[email-masked]>
Date: Wed, 28 Mar 2018 05:59:57 +0000 (UTC)

This has been discussed a fair amount; non-ASCII payloads in headers is pretty rare (since headers are generally not displayed to users).

You could encode it as binary, or you could use percent-encoding inside a string.

If there's significant demand for it, we could add a new type, but then we need to be able to discriminate it from ascii strings -- both on the wire and in APIs.

-- 
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/537#issuecomment-376771095

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 28 Mar 2018 06:39:09 +0000 (UTC)

It'd be good to have use cases indeed. The only case I've seen folks make for this is URLs, which end up being ASCII-compatible once parsed, so are not that compelling.

If we do this a variant on binary makes the most sense to me, where we run https://encoding.spec.whatwg.org/#utf-8-decode-without-bom-or-fail on the bytes before returning the value.

-- 
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/537#issuecomment-376778353

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 28 Mar 2018 23:39:01 -0700

One thing I'm running into is providing a Title for a link. Basically the specification is saying right now is that Headers are strictly identifiers for computers, and never information for humans.

-- 
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/537#issuecomment-377137509

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 29 Mar 2018 06:45:06 +0000 (UTC)

I think it's saying that UI is the exceptional case and that in such exceptional cases you can use "binary" plus UTF-8 processing on top.

-- 
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/537#issuecomment-377138565

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 29 Mar 2018 17:39:13 +0000 (UTC)

While I understand the argument that it might not be an extremely common case, I am kind of left wondering what the specific argument *against* UTF-8 support, especially in light of the fact that an established mechanism for this exists. 

-- 
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/537#issuecomment-377314510

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 29 Mar 2018 15:24:57 -0700

Because developers have been trained to use it, and if it's available as a "native" option, will use it out of habit / cargo culting.

While in most places UTF-8 is clearly the right thing to do, this is not at all true in protocols; years of experience has shown that it causes performance overhead, bloat, imprecision, confusion, and sometimes security issues.

It's better to make the right thing easier to do (strings) and make the usually not-right thing harder to do (utf-8). One of the objectives for Structured Headers is to leave as few foot guns lying around as possible.

-- 
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/537#issuecomment-377391068

---

From: HTTP issue updates <[email-masked]>
Date: Fri, 30 Mar 2018 07:36:14 +0000 (UTC)

Sounds like a solid reason. At least we still have the other syntax for anything else.

-- 
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/537#issuecomment-377467150