I am running MVC 5 and have a search API that produces the following link: /SearchedItem.?format=json where SearchedItem. is the user's input into search. This obviously causes a famous 404 due to a dot character. I've looked into all of the following solutions:
Dot character '.' in MVC Web API 2 for request such as api/people/STAFF.45287
Dots in URL causes 404 with ASP.NET mvc and IIS
ApiController returns 404 when ID contains period
However, neither adding a slash (tried both /SearchedItem./?format=json and /SearchedItem.?format=json/) nor RAMMFAR worked.
Looking for any new suggestions.
You have to change your web.config, the trailing dot let's iis think you are accessing an image.
Add the following within the system.webServer / handlers ( web.config)
<add name="ApiURIs-ISAPI-Integrated-4.0"
path="/api/*"
verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS"
type="System.Web.Handlers.TransferRequestHandler"
preCondition="integratedMode,runtimeVersionv4.0" />
Another suggest would be to set RunAllManagedModulesForAllRequests to true, but i wouldn't recommend that. All static assets would be handled through the .net code then :)
I see in your question that you checked related links. But are you sure? Because i have came accross this in the past and above was my solution...
Most suitable way is to encode once you route to url and decode in the respective action you can use HttpUtility to perform encoding and decoding
If you don't want to encode and decode then try adding relaxedUrlToFileSystemMapping config as explained Here
Related
I'm working on a web api call that includes parameters with '&'.
I've tried uriEncodingComponent to get the following thinking it was going to fix the issue but I am still running into the same problem. The url I'm trying to reach is here below.
http://localhost:123/api/Apples/GetApples/Red%20%26%20Green/20
I have also tried changing the HTTPRuntime in my application, without any success, to the following:
<httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="<,>,*,%,:,\,?" />
Any help is greatly appreciated!
The WebAPIConfig had constraints that was not including &. Included modified my regex expression to accept the character.
In my web application I have a route which looks like this:
routeCollection.MapRoute(
"AdfsMetadata", // name
"FederationMetadata/2007-06/FederationMetadata.xml", // url
new { controller = "AdfsController", action = "MetaData" }); // defaults
The idea behind this route was to work better with Microsoft AD FS server (2.0+) which looks for AD FS metadata at this point when you just specify a host name. With MVC3 all worked fine. But we upgraded the project to MVC4 recently and now the call for this URL results in a 404, the handler mentioned on the error page is StaticFile and the physical path is D:\path\to\my\project\FederationMetadata\2007-06\FederationMetadata.xml. I assume that MVC or ASP.NET "thinks" it must be a request for a static file and looks for the file, but it isn't a file. The data is generated dynamically - that's why I routed the URL to a controller action. The problem is that even the Route Debugger by Phil Haack doesn't work. It's just a 404 with no further information besides that IIS tried to access a physical file which isn't there.
Does anyone have a solution for this? I just want this URL to be routed to a controller action.
P.S.: I'm not 100% sure that the cause was the upgrade to MVC4, it was just a guess because the error occurred at about the same time as the upgrade, and the same route works in another project which is still using MVC3.
Edit:
I have a custom ControllerFactory which needs the full class name (AdfsController instead of Adfs), so the suffix Controller is correct in this case.
Add the following to the <handlers> section of the <system.webServer> node:
<add
name="AdfsMetadata"
path="/FederationMetadata/2007-06/FederationMetadata.xml"
verb="GET"
type="System.Web.Handlers.TransferRequestHandler"
preCondition="integratedMode,runtimeVersionv4.0" />
This instructs IIS that GET requests to the specified url should be handled by the managed pipeline and not considered as static files and served by IIS directly.
I have a custom ControllerFactory which needs the full class name
(AdfsController instead of Adfs), so the suffix Controller is correct
in this case.
Double check this please. Try with and without the Controller suffix in the route definition.
IIS by default is serving that file as static withouth going into ASP pipeline, can you change the route to not have a .xml extension (which is not necessary at least you have a specific requirement about that)
You can specifiy the route like this:
routeCollection.MapRoute(
"AdfsMetadata", // name
"FederationMetadata/2007-06/FederationMetadata", // url
new { controller = "AdfsController", action = "MetaData" }); // defaults
Other solution would be to add to your web.config
<modules runAllManagedModulesForAllRequests="true">
but I recommend you to avoid this as possible since what it does is to stop IIS from serving all static files
EDIT Last try... a custom http handler for that specific path would work. This post is similar to your problem only that with images (look for "Better: Custom HttpHandlers" section)
I wrote the code in global.asax contain this
oRoutes.MapPageRoute("test-route", "home/{cURL}", "~/test.aspx");
everything fine, but had error when URL contains "." symbol. And I add the code below just can fix only one dot in URL.
<httpRuntime relaxedUrlToFileSystemMapping="true" />
For Example, when I call http://foo.com/home/open.door.foo/, the routing failed.
Is there any simple way to fix this problem? thanks.
P.S 1: please don't provide the way to remove last words like ".foo", because there could be occur in my URL like http://foo.com/hey.john.open.the.book.volume.1-brabra :-)
P.S 2: For some reason, I must be use "." symbol in URL. :'(
I guess based on several posts here in SO, you should encode your values
ASP.NET MVC: How to Route Search Term with . (Period) at the end
Semantic urls with dots in .net
http://site.com/page%3fcharacter
This URL will return the following error:
Illegal characters in path.
I'm already put this in web.config:
<system.web>
<httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="" />
<pages validateRequest="false">
...
How can I fix this error?
If you want to allow the request through, you need to add requestPathInvalidCharacters and set it to an empty string:
<system.web>
<httpRuntime requestPathInvalidCharacters="" />
</system.web>
Edit You should leave your original question in place, because now my answer does not make sense.
But in answer to your second question, that it's because %3f corresponds to '?' which is not allowed in file names on Windows. You can set the relaxedUrlToFileSystemMapping property to true to change this behaviour:
<system.web>
<httpRuntime requestPathInvalidCharacters=""
relaxedUrlToFileSystemMapping="true" />
</system.web>
You might want to look through all of the properties in the HttpRuntimeSection class to see if there's any others that might apply.
You can also implement a sub class of RequestValidator and set up your web.config to use your subclass (that will presumably allow all URLs through?). Personally, I wouldn't bother and just let the built-in classes handle it. It's unlikely that a normal user is every going to accidentally type in "%3f" in a path, and why bother going to so much trouble to improve the use-case for malicious users?
This, by the way, is actually a new feature in ASP.NET 4, which is why Stack Overflow doesn't spit out an error: it's running on .NET 3.5.
Here's a nice article by Hanselman explaining all the nooks and crannies related to your issue:
Experiments in Wackiness: Allowing percents, angle-brackets, and other naughty things in the ASP.NET/IIS Request URL
Probably because that looks a lot like a malformed url.
& is used as a separator for the query string parameters i.e. site.com/page?some=20&another=15
The Scenario
I have an application where we took the good old query string URL structure:
?x=1&y=2&z=3&a=4&b=5&c=6
and changed it into a path structure:
/x/1/y/2/z/3/a/4/b/5/c/6
We're using ASP.NET MVC and (naturally) ASP.NET routing.
The Problem
The problem is that our parameters are dynamic, and there is (theoretically) no limit to the amount of parameters that we need to accommodate for.
This is all fine until we got hit by the following train:
HTTP Error 400.0 - Bad Request
ASP.NET detected invalid characters in the URL.
IIS would throw this error when our URL got past a certain length.
The Nitty Gritty
Here's what we found out:
This is not an IIS problem
IIS does have a max path length limit, but the above error is not this.
Learn dot iis dot net
How to Use Request Filtering
Section "Filter Based on Request Limits"
If the path was too long for IIS, it would throw a 404.14, not a 400.0.
Besides, the IIS max path (and query) length are configurable:
<requestLimits
maxAllowedContentLength="30000000"
maxUrl="260"
maxQueryString="25"
/>
This is an ASP.NET Problem
After some poking around:
IIS Forums
Thread: ASP.NET 2.0 maximum URL length?
http://forums.iis.net/t/1105360.aspx
it turns out that this is an ASP.NET (well, .NET really) problem.
The heart of the matter is that, as far as I can tell, ASP.NET cannot handle paths longer than 260 characters.
The nail in the coffin in that this is confirmed by Phil the Haack himself:
Stack Overflow
ASP.NET url MAX_PATH limit
Question ID 265251
The Question
So what's the question?
The question is, how big of a limitation is this?
For my app, it's a deal killer. For most apps, it's probably a non-issue.
What about disclosure? No where where ASP.NET Routing is mentioned have I ever heard a peep about this limitation. The fact that ASP.NET MVC uses ASP.NET routing makes the impact of this even bigger.
What do you think?
I ended up using the following in the web.config to solve this problem using Mvc2 and .Net Framework 4.0
<httpRuntime maxUrlLength="1000" relaxedUrlToFileSystemMapping="true" />
Http.sys service is coded with default maximum of 260 characters per Url segment.
An "Url segment" in this context is the content between "/" characters in the Url. For example:
http://www.example.com/segment-one/segment-two/segment-three
The max allowed Url segment length can be changed with registry settings:
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters
Value: UrlSegmentMaxLength
Type: REG_DWORD
Data: (Your desired new Url segment maximum allowed length, e.g. 4096)
More about http.sys settings:
http://support.microsoft.com/kb/820129
The maximum allowed value is 32766. If a larger value is specified, it will be ignored. (Credit: Juan Mendes)
Restarting the PC is required to make a change to this setting take effect. (Credit: David Rettenbacher, Juan Mendes)
To solve this, do this:
In the root web.config for your project, under the system.web node:
<system.web>
<httpRuntime maxUrlLength="10999" maxQueryStringLength="2097151" />
...
In addition, I had to add this under the system.webServer node or I got a security error for my long query strings:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxUrl="10999" maxQueryString="2097151" />
</requestFiltering>
</security>
...
OK so part of the reason I posted this was also because we have found a work around.
I hope this will be useful to someone in the future :D
The workaround
The workaround is quite simple, and it's quite nice too.
Since we know which parts of the site will need to use dynamic parameters (and hence will have a dynamic path and length), we can avoid sending this long url to ASP.NET routing by intercepting it before it even hits ASP.NET
Enter IIS7 Url Rewriting (or any equivalent rewrite module).
We set up a rule like this:
<rewrite>
<rules>
<rule>
<rule name="Remove Category Request Parameters From Url">
<match url="^category/(\d+)/{0,1}(.*)$" />
<action type="Rewrite" url="category/{R:1}" />
</rule>
</rules>
</rewrite>
Basically, what we're doing is just keeping enough of the path to be able to call the correct route downstream. The rest of the URL path we are hacking off.
Where does the rest of the URL go?
Well, when a rewrite rule is fired, the IIS7 URL Rewrite module automagically sets this header in the request:
HTTP_X_ORIGINAL_URL
Downstream, in the part of the app that parses the dynamic path, instead of looking at the path:
HttpContext.Request.Url.PathAndQuery
we look at that header instead:
HttpContext.Request.ServerVariables["HTTP_X_ORIGINAL_URL"]
Problem solved... almost!
The Snags
Accessing the Header
In case you need to know, to access the IIS7 Rewrite Module header, you can do so in two ways:
HttpContext.Request.ServerVariables["HTTP_X_ORIGINAL_URL"]
or
HttpContext.Request.Headers["X-ORIGINAL-URL"]
Fixing Relative Paths
What you will also notice is that, with the above setup, all relative paths break (URLs that were defined with a "~").
This includes URLs defined with the ASP.NET MVC HtmlHelper and UrlHelper methods (like Url.Route("Bla")).
This is where access to the ASP.NET MVC code is awesome.
In the System.Web.Mvc.PathHelper.GenerateClientUrlInternal() method, there is a check being made to see if the same URL Rewrite module header exists (see above):
// we only want to manipulate the path if URL rewriting is active, else we risk breaking the generated URL
NameValueCollection serverVars = httpContext.Request.ServerVariables;
bool urlRewriterIsEnabled = (serverVars != null && serverVars[_urlRewriterServerVar] != null);
if (!urlRewriterIsEnabled) {
return contentPath;
}
If it does, some work is done to preserve the originating URL.
In our case, since we are not using URL rewriting in the "normal" way, we want to short circuit this process.
We want to pretend like no URL rewriting happened, since we don't want relative paths to be considered in the context of the original URL.
The simplest hack that I could think of was to remove that server variable completely, so ASP.NET MVC would not find it:
protected void Application_BeginRequest()
{
string iis7UrlRewriteServerVariable = "HTTP_X_ORIGINAL_URL";
string headerValue = Request.ServerVariables[iis7UrlRewriteServerVariable];
if (String.IsNullOrEmpty(headerValue) == false)
{
Request.ServerVariables.Remove(iis7UrlRewriteServerVariable);
Context.Items.Add(iis7UrlRewriteServerVariable, headerValue);
}
}
(Note that, in the above method, I'm removing the header from Request.ServerVariables but still retaining it, stashing it in Context.Items. The reason for this is that I need access to the header value later on in the request pipe.)
Hope this helps!
I was having a similar max URL length issue using ASP.NET Web API 4, which generated a slightly different error:
404 Error
The fix for me was described above by updating the Web.config with BOTH of the following tags:
<system.web>
<httpRuntime maxUrlLength="10999" maxQueryStringLength="2097151" />
and
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxUrl="10999" maxQueryString="2097151" />
</requestFiltering>
</security>
I think you're trying to hard to use GET. Try changing the request method to POST and put those query string parameters into the request body.
Long URL does not help SEO as well, does it?
It appears that the hard-coded max URL length has been fixed in .NET 4.0. In particular, there is now a web.config section with:
<httpRuntime maxRequestPathLength="260" maxQueryStringLength="2048" />
that let you expand the range of allowed URLs.