Specify for which URL component to encode in DefaultUrlEncoder

[antoinebj]

Currently, the System.Text.Encodings.Web.DefaultUrlEncoder class forces a set of forbidden characters that is the union of all forbidden characters in all components of the URL.
That is regardless of what was specified as allowed in the TextEncoderSettings that can be injected through the constructor.

In my use case, I'd like to encode for the query string only. For example, I would benefit from the : not being encoded, which is allowed in query strings. However, that character is being encoded, because a URL component other than the query string disallows it.

Would it be possible to enhance the DefaultUrlEncoder in one or more of the following ways?

1. To take a hint of which URL component is being passed for encoding, and leave acceptable characters for that component untouched (e.g. the colon character for query strings)

OR

2. To honor the TextEncoderSettings to truly override what is allowed or forbidden

OR/AND

3. To make it public and non-sealed in order to be able to override its behavior (in particular the WillEncode and FindFirstCharacterToEncode methods)

[davidsh]

Which .NET Core class are you referring to? I can't find 'DefaultUrlEncoder' as a type name in .NET Core.

[antoinebj]

Sorry, I'll edit the OP to add the full name:
System.Text.Encodings.Web.DefaultUrlEncoder
https://github.com/dotnet/corefx/blob/master/src/System.Text.Encodings.Web/src/System/Text/Encodings/Web/UrlEncoder.cs

[GrabYourPitchforks]

Punting this to Future since I don't think we'll get to it in the 5.0 timeframe.

The point of the base encoder classes is that they're intended to be safe for any application where the data might appear. For instance, HtmlEncoder.Encoder should produce data that's safe regardless of whether it appears <foo>within an HTML element</foo> or <foo attr="within an HTML attribute" />. JavaScriptEncoder.Encode should produce data that's safe regardless of whether it appears var data = "within a JS literal string"; or { "foo": "within a JSON literal string" }. UrlEncoder.Encode should produce data that's safe regardless of whether it appears /within_a_path/ or ?q=within_a_query_string. And so on.

If we introduced a query-string specific API, I don't think we should change the behavior of UrlEncoder.Encode. It would mean that if you're given an arbitrary UrlEncoder instance, you wouldn't be able to reason about what its intended use case is.

Instead, we should introduce a separate API UrlEncoder.EncodeQueryString (or similar) if we wanted to address this. That way there's no ambiguity as to what the intent of the code is.

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of the experimental issue cleanup initiative we are currently trialing in a limited number of areas. Please share any feedback you might have in the linked issue.

This issue will now be closed since it had been marked no recent activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.