Subject: Re: [httpwg/http-extensions] How to handle non-canonical base64? (#473)

From: HTTP issue updates <[email-masked]>
Date: Tue, 30 Jan 2018 09:13:22 -0800

Belatedly, I'd propose matching https://infra.spec.whatwg.org/#forgiving-base64-decode, which ignores pad bits and explicitly says that having 1 base64 character left over is an error.

-- 
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/473#issuecomment-361664878

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 30 Jan 2018 09:33:17 -0800

I don't see why we need to leave IETF land here. Just specify something that is well-defined and based on RFC 4648.

-- 
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/473#issuecomment-361671109

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 30 Jan 2018 09:45:52 -0800

Yeah, matching the WHATWG spec doesn't mean we have to reference it. Just copy its behavior so web developers have only 1 thing to learn.

-- 
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/473#issuecomment-361675098

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 31 Jan 2018 00:40:39 +0000 (UTC)

I don't particularly want to specify the algorithm for decoding base64 in detail here, since that's the purview of RFC4648 (and whatever follows it). I think we can address this by saying something like:

> Decoders MUST NOT reject base64 encoded data if pad bits have not been set to zero; see [RFC4648], Section 3.5. Therefore, both "YQ" and "YR" decode to "a" (for example).

Does that work?

-- 
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/473#issuecomment-361784080

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 30 Jan 2018 19:31:56 -0800

Why would we want to be forgiving?  That's an end state you reach when [your ecosystem has rotted](https://martinthomson.github.io/postel-was-wrong/draft-thomson-postel-was-wrong.html).

-- 
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/473#issuecomment-361813008

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 30 Jan 2018 20:02:44 -0800

It's worth noting that the rest of structured headers is currently pretty draconian, so as to prevent such rot. Not sure that having one thing to learn is worth the tradeoff -- especially when the vast majority will be using tools that *should* get this right.

-- 
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/473#issuecomment-361817087

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 30 Jan 2018 20:06:07 -0800

My main goal is to define *something*, so being strict is fine with me.

-- 
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/473#issuecomment-361817507

---

From: HTTP issue updates <[email-masked]>
Date: Wed, 31 Jan 2018 22:41:45 -0800

Closed #473 via 9b495e3160af1c3c0b473a194d968ee5b8c470d1.

-- 
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/473#event-1452320066

---

From: HTTP issue updates <[email-masked]>
Date: Thu, 01 Feb 2018 06:42:15 +0000 (UTC)

See how that works - happy to reopen.

-- 
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/473#issuecomment-362173504