- From: Anne van Kesteren <notifications@github.com>
- Date: Tue, 17 Jan 2023 01:42:25 -0800
- To: whatwg/url <url@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/url/issues/729/1385107546@github.com>
From https://www.rfc-editor.org/rfc/rfc3986.html#section-6.2 I think we would want this method to perform "Case Normalization" (essentially only of the `%3a` to `%3A` variety) and "Percent-Encoding Normalization". The other aspects there are either already handled by the URL parser (e.g., `httpS://EXAMPLE.com:443/%7ESMith/./home.html` is already normalized to `https://example.com/%7ESMith/home.html`) or out-of-scope. We wouldn't want to offer scheme-based or protocol-based normalization as that's not tenable and better handled by the standards for those schemes and protocols. HTTP(S) schemes end up being covered anyway, but in general schemes are supposed to build on top of the URL Standard. Now there are some difficulties with "Percent-Encoding Normalization", e.g., `https://test/?%%33a`. That would have to become `https://test/?%253a` presumably, but it's not entirely clear as the input is invalid. And yeah, assuming `application/x-www-form-urlencoded` for query and normalizing that could make sense to offer as an option, though you could also do this yourself quite easily with `url.searchParams.sort()`. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/url/issues/729#issuecomment-1385107546 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/url/issues/729/1385107546@github.com>
Received on Tuesday, 17 January 2023 09:42:37 UTC