- From: David Benjamin <notifications@github.com>
- Date: Wed, 20 Mar 2019 05:04:27 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 20 March 2019 12:04:48 UTC
> 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
Received on Wednesday, 20 March 2019 12:04:48 UTC