Provide an option on FromRouteAttribute that allows decoding the value being bound

[SchroterQuentin]

The rights of my users are at /api/admin/users/{userId}/rights

And my controller is as simple as

[Route("/api/admin/users/{userId}/rights")]
public async Task<IActionResult> GetRights([FromRoute]string userId)
{
    var rights = await _someService.GetRights(userId);
    return Ok(rights);
}

or

[HttpPut("{userId}")]
public async Task<IActionResult> Update(string userId, [FromBody]UpdateUserViewModel parameters)
{
    var user = await _employeService.Update(userId, parameters);
    return Ok(user);
}

The problem I have is that, the userIds of my users may contains a / which is encoded to %2F in the Uri. But userId doesn't decode %2F so my string contains %2F. It's fine for me, I can deal with that.

But the userIds of my users may contains a + which is encoded to %2B in the Uri. And now, the userId decode the %2B to + 😲

Currently, I can't use WebUtility.UrlDecode(userId) because userId may contains a + which would be send as %2B decoded as + and finally to . My only actual solution is to replace %2F to / which is ugly and does not solve all the possibility : %252F

I saw a recommandation to use [FromQuery] instead of [FromRoute] but it's obvious that if both exist, it's because they have semantic difference.

It seems that's not the first time the problem appears : aspnet/Mvc#4599, #2655, #4445 and I'd like to know if it's on the roadmap to change this behavior or not.

Could you please this time consider this bug ? I'd be happy to help.

[mkArtakMSFT]

Thanks for contacting us, @SchroterQuentin.
We'll provide an option so that FromRoute attribute decodes specific (by you) parameters.

[SchroterQuentin]

The problem exist on [HttpGet] [HttpPost] [HttpPut] etc. Is there a way to handle all this problems in one area ? Or do we have to add this options on all this attributes ?

I'm actually not understanding how would work this option ?

[bachratyg]

Also see aspnet/Mvc#6388

The hosts partially decodes the percent encoding and explicitly skips decoding %2F here:

Microsoft.AspNetCore.Server.IIS > Microsoft.AspNetCore.HttpSys.Internal.RequestUriBuilder.UnescapePercentEncoding
Microsoft.AspNetCore.Server.HttpSys > Microsoft.AspNetCore.HttpSys.Internal.RequestUriBuilder.UnescapePercentEncoding
Microsoft.AspNetCore.Server.Kestrel.Core > Microsoft.AspNetCore.Internal.UrlDecoder.UnescapePercentEncoding

The main problem is Routing or MVC model binding cannot reliably decode the partially decoded segment. Ideally the server should not do any decoding especially not partial. (Full decoding is not possible since it would introduce new segments.)

If the server behavior is not allowed to change (even behind a compatibility flag) then the router middleware could be modified to use the raw request url from IHttpRequestFetaure.RawTarget (which is not yet decoded) to get proper encoded tokens then decode as needed.

A possible workaround: inject a middleware before routing takes place that restores the original undecoded path from IHttpRequestFeature.RawTarget then in another middleware after routing decode the RouteData tokens.

[pranavkm]

As part of doing this, ensure binding to non-string values that require decoded values work. See #11134

[ArthurHNL]

Can we get an update on this? I just spent half an hour debugging my API before I found out that Route parameters are not URL decoded by default.

[DanielBryars]

Yeah, this behaviour is pretty weird.

If you can't fix it then this FromRouteAttribute option would be a good compromise for me. Or perhaps provide an example implementation of the middleware suggested by https://github.com/Eilon in aspnet/Mvc#6388

[stefanluchian]

I see that this bug lives since at least 2017 and there is not even a workaround about it.
In .Net Core you don't allow us to do WCF anymore, so we are forced to do REST.
In REST we need to send parameters via Route, not via Query.
So we need to use [FromRoute], which should happen short before Model-Binding, but definitely after Routing.
So there is no worry about decoding %2B into /.
Then why is nothing happening here?
You closed any other Issues (at least 4 peaces counted) and now you let this open for loooong time.
How many developers do you need to comment on this issue, before you consider it worthy to look upon?

[pranavkm]

Can we get an update on this?

We will consider fixing this in the upcoming 5.0 release. That said, the plan is to not have this decoding on by default - you explicitly would have to opt-in to this behavior. For current releases, you should be able to unblock yourselves by explicitly url decoding values in your action that you know require to be decoded.

[mkArtakMSFT]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[skovalyova]

I face the same issue when passing encoded URI as part of route. In this case, : is decoded automatically, but // remain encoded (http:%2F%2F). I have to use HttpUtility.UrlDecode as a workaround or use query parameters instead.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[thegrahamking]

We are experiencing this issue and, running on Azure App Service, have yet to find a workaround other than switching to FromQuery which makes this one route inconsistent with all the others in our RESTful service.

This issue needs to be fixed or a code example of a valid workaround which allows us to continue using FromRoute provided.

[Nils-Berghs]

BUMP, please stop development on .net 8, and fix bugs like this first....

• Moved to 3.1 milestone (Jun 2019)
• Moved to 5 planning (Jan 2020)
• Moved to 6 planning
• Moved to 7 planning (Dec 2021)
• Moved to 8 planning (Oct 2022)

More managers / scrum master than developers?

[davidfowl]

cc @Tratcher

[Tratcher]

The real fix here is much deeper: #30655. The server needs to make the path available as individual, fully decoded segments so that the the app / model binder isn't left dealing with this ambiguous escaping state. Routing would need to be updated to consume the path as individual segments. Model binding shouldn't need to be updated once routing is delivering the correct route values.

[JMonsorno]

Following the example from @celluj34 I made a sample app and library, don't judge the 5.0 references, that works for my purposes and addresses others concerns; namely @Nils-Berghs example and my own of raw "%2525" testcase. Feeling it's a bit unpolished for a nuget package but will decode the raw route - following some Angular influences I called "unsafe" - or if you want the controller to handle it uniquely it return back the raw value all by application level setup and controller level replacement of [FromRoute] with [FromRouteUnsafe] or [FromRouteRaw] respectively.

https://github.com/JMonsorno/CustomRouteBinderProvider

[code-bringer]

I've just encountered this bug :( Is there any update on it? It would be nice to have some options that may change routing behavior for this specific case with slash encoding.
My use case is the following:
I have entity keys from multiple external systems, for some of them these keys look like numbers, for others, it could be guids. But of course, there is a system with keys that with slashes inside(it mimics some folder structure).
So in my case, I already have multiple endpoints with the following routing scheme:

[HttpGet("documents/for/{externalKeyId}/{documentType}")]
public async IAsyncEnumerable<Document> GetDocuments(
	[FromRoute] string externalKeyId,
	[FromRoute] DocumentType documentType,
	[FromQuery] DateTime? startDate,
	[FromQuery] DateTime? endDate,
	[EnumeratorCancellation] CancellationToken cancel = default
)

So as you can see keys with slashes inside are real pain in the neck.

[Odonno]

Having a use case for this at the moment, it is frustrating to have an incomplete decoded string. %20 works fine but not %2F.

I am gonna go with the solution provided by @JMonsorno until a definitive solution is implemented.

[rudism]

Here's my slightly simplified version of @JMonsorno's code that will apply the modified decoding behavior to all [FromRoute] string parameters by default without using custom parameter attributes:

using Microsoft.AspNetCore.Http.Features;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.ModelBinding;
using Microsoft.AspNetCore.Mvc.ModelBinding.Binders;
using Microsoft.AspNetCore.Mvc.ModelBinding.Metadata;

namespace My.Project.Namespace;

public class RouteUnsafeBinder : IModelBinder {
  public Task BindModelAsync(ModelBindingContext bindingContext) {
    ArgumentNullException.ThrowIfNull(bindingContext);

    var modelName = bindingContext.ModelName;

    // make sure the param we want was extracted in the standard method
    // this will be the partially-decoded value that we're looking to avoid using here
    if (!bindingContext.ActionContext.RouteData.Values.ContainsKey(modelName))
      throw new NotSupportedException();

    // wrap the param in curly braces so we can look for it in the [Route(...)] path
    var templateToMatch = $"{{{modelName}}}";

    // if this is null then the developer forgot the [Route(...)] attribute
    var request = bindingContext.HttpContext.Request;
    var template = (bindingContext.ActionContext.ActionDescriptor.AttributeRouteInfo?.Template)
      ?? throw new NotSupportedException();

    // get the raw url that was called
    var rawTarget = bindingContext.HttpContext.Features.Get<IHttpRequestFeature>()?.RawTarget
      ?? throw new NotSupportedException();
    // strip the query string
    var path = new Uri($"{request.Scheme}://{request.Host}{rawTarget}").AbsolutePath;

    // go through route template and find which segment we need to extract by index
    var index = template
      .Split('/', StringSplitOptions.RemoveEmptyEntries)
      .Select((segment, index) => new { segment, index })
      .SingleOrDefault(iter =>
          iter.segment.Equals(templateToMatch, StringComparison.OrdinalIgnoreCase))
      ?.index;

    var segments = path.ToString().Split('/', StringSplitOptions.RemoveEmptyEntries);

    if (index.HasValue) {
      // extract and decode the target path segment
      var rawUrlSegment = segments[index.Value];
      var decoded = Uri.UnescapeDataString(rawUrlSegment);
      bindingContext.Result = ModelBindingResult.Success(decoded);
    } else {
      // can't think of any scenarios where we'd hit this
      throw new NotSupportedException();
    }

    return Task.CompletedTask;
  }
}

public class FromRouteUnsafeModelBinder : IModelBinderProvider {
  public IModelBinder? GetBinder(ModelBinderProviderContext context) {
    if (context.Metadata is not DefaultModelMetadata metadata) return null;
    var attribs = metadata.Attributes.ParameterAttributes;
    return attribs == null
      ? null
      // handle all [FromRoute] string parameters
      : attribs.Any(pa => pa.GetType() == typeof(FromRouteAttribute))
          && metadata.ModelType == typeof(string)
        ? new BinderTypeModelBinder(typeof(RouteUnsafeBinder))
        : null;
  }
}

I apply this binder at startup when I'm configuring services like this:

    services.AddControllers(opts => {
      opts.ModelBinderProviders.Insert(0, new FromRouteUnsafeModelBinder());
    })

[mikekistler]

This is dropped from the .NET 10 Roadmap due to resource constraints.