[API Proposal]: Uri from interpolated string

[scalablecory]

Background and motivation

I frequently see code like this:

new Uri($"http://localhost/things/{Uri.EscapeDataString(id)}/?foo={Uri.EscapeDataString(foo)}")
new Uri(baseUri, $"/things/{Uri.EscapeDataString(id)}/?foo={Uri.EscapeDataString(foo)}")

I'd rather do something like:

Uri.Create($"/things/{id}/?foo={foo}", UriKind.Relative);
Uri.Create($"http://localhost/things/{id}/?foo={foo}", UriKind.Absolute);
Uri.Create($"{baseUri}/things/{id}/?foo={foo}");

(Note, this is integrating the "base uri" into the format string. Not sure of corner cases but it feels pretty natural)

May be able to use a format string to indicate "%20" vs "+" style escaping.

API Proposal

ref struct UriInterpolatedStringHandler
{
    // all the interpolated handler members.
}

class Uri
{
    public static Uri Create(ref UriInterpolatedStringHandler handler);
}

API Usage

string GetThingFromWebService(HttpClient client, string thingId)
{
    Uri uri = Uri.Create($"{client.BaseUri}/things/{thingId}/");

    using var req = new HttpRequestMessage { Uri = uri };
    // ...
}

Alternative Designs

No response

Risks

No response

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

I frequently see code like this:

new Uri($"http://localhost/things/{Uri.EscapeDataString(id)}/?foo={Uri.EscapeDataString(foo)}")
new Uri(baseUri, $"/things/{Uri.EscapeDataString(id)}/?foo={Uri.EscapeDataString(foo)}")

I'd rather do something like:

Uri.Create($"/things/{id}/?foo={foo}", UriKind.Relative);
Uri.Create($"http://localhost/things/{id}/?foo={foo}", UriKind.Absolute);
Uri.Create($"{baseUri}/things/{id}/?foo={foo}");

(Note, this is integrating the "base uri" into the format string. Not sure of corner cases but it feels pretty natural)

May be able to use a format string to indicate "%20" vs "+" style escaping.

API Proposal

ref struct UriInterpolatedStringHandler
{
    // all the interpolated handler members.
}

class Uri
{
    public static Uri Create(ref UriInterpolatedStringHandler handler);
}

API Usage

string GetThingFromWebService(HttpClient client, string thingId)
{
    Uri uri = Uri.Create($"{client.BaseUri}/things/{thingId}/");
}

Alternative Designs

No response

Risks

No response

Author:	scalablecory
Assignees:	-
Labels:	api-suggestion, area-System.Net, untriaged
Milestone:	-

[MihaZupan]

I really like this idea, it's essentially an InterpolatedStringHandler spin on better APIs around building query strings, right?

Presumably, the implementation here would be to look for ? to decide which arguments to encode and then delegate to the existing APIs after creating the string.
This would be both simpler for the user to encode stuff correctly as well more performant since we can do a lot better than
string EscapeDataString(string) internally.

From an API perspective, I agree we want a different method name to avoid breaking existing uses of new Uri($"foo").

We already have TryCreate and we can't change its existing behavior, so Create($"") and TryCreate($"") would behave a lot differently. For this reason, I'm not sure we can call it Create.

Do we care about the Try- scenario at all? I would say no, given that you are creating new Uris with custom arguments, which should never result in an invalid format.

Do we care about other overloads (UriKind, UriCreationOptions)?

Related: #32606, #40603
cc: @NinoFloris @stevejgordon

[stephentoub]

Presumably, the implementation here would be to look for ? to decide which arguments to encode

Can you elaborate on that? Cory's example appears to be wanting to escape the holes both before and after ? has appeared

[MihaZupan]

Including the path complicates it somewhat.

I was thinking of examples where the base/authority portion of the Uri is also a hole, but you wouldn't want it to be escaped.

Uri.Create($"{baseUri}/things/{id}/?foo={foo}");
Uri.Create($"{scheme}://{host}:{port}/things/{id}/?foo={foo}");
Uri.Create($"https://{authority}/things/{id}/?foo={foo}");

// Some weirder cases, but not necessary the most realistic
Uri.Create($"https://{authority}/{pathPrefix}/?foo={foo}"); // pathPrefix is escaped
Uri.Create($"https://{authority}{pathPrefix}/?foo={foo}"); // does pathPrefix contain the leading '/'? You'll get weird results
Uri.Create($"https://{authorityAndPathPrefix}/?foo={foo}"); // the path prefix is not escaped?

We would have to evaluate both the constants & holes to determine where the path starts, then encode all the holes following it.

Either that, or be strict about always escaping all holes, but that seems harder on the user in the
$"{baseUri}/things/{id}/?foo={foo}" case.

Arguably with HttpClient, they could set BaseUri and pass in a relative Uri.

string GetThingFromWebService(HttpClient client, string thingId)
{
-   Uri uri = Uri.Create($"{client.BaseUri}/things/{thingId}/");
+   Uri uri = Uri.Create($"/things/{thingId}/");

[scalablecory]

Perhaps base URI should not be part of the string. It looks weird as $"{baseUri}foo" --- and might be more confusing, since it's so visually "URLish" as a string, when discussing "foo" vs "foo/" as base uri.

It'd be super cool to have it just "know" the correct escaping, as you have discussed.

[MihaZupan]

Just playing around implementation-wise, did you have something like this (untested) in mind?

[scalablecory]

Just playing around implementation-wise, did you have something like this (untested) in mind?

Yes. I like the direction you've taken it w/ implementation.

• Would this always do EscapeDataString for bits in the path/query, or would it somehow give the caller the option?
• You're special-casing those types; but I don't know if it holds for all cultures & format strings.
• Crazy idea, but just throwing it out there -- could the interpolated string builder also be used directly as a maybe more efficient UriBuilder?
• Can you also drop in a hostname and port?
• Would an overload that outputs to Span be useful for anything?

[MihaZupan]

Would this always do EscapeDataString for bits in the path/query, or would it somehow give the caller the option?

This would escape every hole. What would user configuration look like here? Presumably, we would want to be clear that this method "always" escapes vs. the existing constructors that just take string and you are always responsible for escaping.

Crazy idea, but just throwing it out there -- could the interpolated string builder also be used directly as a maybe more efficient UriBuilder?

How do you mean? As in users using the handler directly instead of through a helper method?

var builder = new Uri.SomeRandomStringHandlerName(13, 2);
builder.AppendLiteral("/myPath/");
builder.AppendFormatted(guid);
builder.AppendLiteral("/?id=");
builder.AppendFormatted(span);
string uriString = builder.ToString();

It would probably work, but I'm not sure you would want to use that over

string uriString = Uri.CreateRelative($"/myPath/{guid}/?id={span}");

You're special-casing those types; but I don't know if it holds for all cultures & format strings.

I think it's fine for the "default" (unspecified) formatting.
It most likely wouldn't be fine for an arbitrary format, but for those you have to implement different AppendFormatted overloads anyway.
Another thing is also alignment, but I can't think of a reason someone would want to do that with a Uri.

Can you also drop in a hostname and port?

In my experiment, it's CreateRelative just so you can avoid thinking about different parts and always encode everything. That also solves the naming problem with Create.

I haven't tried it to see how complicated it would be to do the above-mentioned logic of finding the start of the path.

Would an overload that outputs to Span be useful for anything?

I could see that being useful to avoid the Uri allocation if you don't need the type itself. Either Span or string.

[karelz]

Triage: Sounds reasonable. Not high priority. Let's see if we can land on API shape.
It might solve other issue around exposing Span for EscapeDataString.

[Shane32]

This would be great, and also a EscapeUriString overload that accepts a FormattableString. It would make building properly-formatted urls much easier and provide a suitable safe replacement for the existing EscapeUriString method which has been marked as obsolete.