Re: [whatwg/fetch] Handling of invalid Location header characters doesn't match browsers (#883)

> I was hoping we could use https://infra.spec.whatwg.org/#isomorphic-encode, but unfortunately that would not match what you are seeing.

Hrm, yeah it seems the URL parser would need to be aware of that. Isomorphic-encode would turn a UTF-8-encoded U+2603 into its UTF-8 decoding encoded as Latin-1, U+00E2, U+0098, U+0083. The URL parser would then try to UTF-8 encode each of those when percent-escaping and do something odd. We could then we have an entry-point to the URL parser that's isomorphic-encode-aware, but that's just a really goofy way to say "byte sequence". May as well just add a byte sequence entry-point to begin with at that point.

> Have you written web-platform-tests when fixing this "regression"?

Not yet, but I'll put some together today. I figured it would make sense to have written something up here and double-check other browser behavior, so I did this first.

(Eh, I think it counted as a regression without the quotes. :-) It wasn't an intentional change, just a refactoring mishap in logging code. Chrome 73's behavior around here is quite nonsense.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/883#issuecomment-474801181