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

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 ?

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.

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

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.

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

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?

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.

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.

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.

I faced the same issue when passing encoded URI as query parameters.
I had to Get a request and I excepted to get a model. one of the props was string and we send encoded string due to we want to pass '+'.

I tried every solution I found on google, but no one work. so I started to try myself and I found a solution. I explicit the get set.
Now all work as expected.

In you example
`[Route("/api/admin/users/{userId}/rights")]
public async Task GetRights([FromRoute]GetRightsRequest userId)
{
var rights = await _someService.GetRights(userId);
return Ok(rights);
}

public class GetRightsRequest
{
private string _userId
public string UserId{get{return _userId;} set{_userId = value;}}
}`

In my case instead [FromRoute] I use [FromQuery] but I think it will work.
In addition, I don't really know why this work, and when I use automatic get set ({get; set;}) it didn't work.

Hi devs, please advise if not dealing the route cause of this issue, please provide a proper workaround this is not that small of a thing, the DOTNET core FW should be working according to REST standards this partial escaping is really a wired behavior :

A workaround is to provide your own model binder and provider:

// Startup.cs : ConfigureServices

            services.AddMvcCore(options =>
                    {
                        options.ModelBinderProviders.Insert(0, new DecodePathStringsBinderProvider());
                    });


    public class DecodePathStringsBinderProvider : IModelBinderProvider
    {
        public IModelBinder? GetBinder(ModelBinderProviderContext context)
        {
            return context.Metadata.ModelType == typeof(string) && context.BindingInfo.BindingSource == BindingSource.Path /* or Route, or whatever you want */ ? new BinderTypeModelBinder(typeof(DecodePathStringsBinder)) : null;
        }
    }

    public class DecodePathStringsBinder : IModelBinder
    {
        public Task BindModelAsync(ModelBindingContext bindingContext)
        {
            if (bindingContext == null)
            {
                throw new ArgumentNullException(nameof(bindingContext));
            }

            var modelName = bindingContext.ModelName;

            // Try to fetch the value of the argument by name
            var valueProviderResult = bindingContext.ValueProvider.GetValue(modelName);
            if (valueProviderResult == ValueProviderResult.None)
            {
                return Task.CompletedTask;
            }

            var value = valueProviderResult.FirstValue;
            var urlDecode = HttpUtility.UrlDecode(value);

            bindingContext.ModelState.SetModelValue(modelName, urlDecode, value);
            bindingContext.Result = ModelBindingResult.Success(urlDecode);

            return Task.CompletedTask;
        }
    }

Thanks for contacting us.

We're moving this issue to the .NET 7 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.

What am I missing? I can't understand that this isn't fixable in 6 years. It is very easy:

• Evaluate the route
• Decode route params
• Pass them to the controller action/page/...

A solution is even given in the workaround described by @celluj34 The soltution described by @celluj34 does NOT always work. It works for the / but if there are other 'escaped' characters in the route param they are already decoded, and decoding them again may cause issues.

Examples (input string in unencoded form):

• 'ab/cd' => decodes ok
• 'ab%cd' => decodes ok
• 'ab%12' => ERROR, in the model binder the % character is already encoded and decoding again will decode %12

THERE IS NO SOLUTION FOR THIS PROBLEM POSSIBLE
An idea would be to replace %2f by /, but there is no way to know if the percentage was already decoded or not!

Is there any reason why route parameters should not be fully URL decoded, by default? I can think of none. And if there is, is it as devastating as the problem above? In short route parameter can not be used in asp .net core (unless you know all possible values in advance....)

For me, this only happens when the controller inherits from ControllerBase class. The workaround for me is that instead of ControllerBase, I inherit the controller from the Controller class.

@asprna I can not confirm this, for me it happens both with Controller and ControllerBase as base class. (Maybe this depends on the .net core version, after all this bug could have been fixed in 3.1)

@Nils-Berghs I am currently using .net core 3.1

@Nils-Berghs Actually you are right. The actual workaround is to get the value from the query string.

[ApiController] [Route("api/v1/[controller]")] public class TestController : ControllerBase { [HttpGet("Successful")] public async Task<IActionResult> Successful([FromQuery] string token) { return Ok(token); } }