On my production ASP.NET MVC 3 site, I've been noticing the occasional "A potentially dangerous Request.Path value was detected from the client (%)." unhandled exception in the Windows application log.
While these can be perfectly valid under regular site usage (ie/ random web bots), a number of the requests appear to be from valid, local ISP users.
In the exception's request details, the Request URL is different than the Request path:
Request URL: http://www.somesite.com/Images/Image With Space.jpg
Request path: /Images/Imagehttp://www.somesite.com/Images/Image With Space.jpgWithhttp://www.somesite.com/Images/Image With Space.jpgSpace.jpg
Notice that in the "request path", any place there is a "space" in the path is replaced with an exact copy of the request url!
Within the site, the actual link looks like this:
<img src="/Images/Image%20With%20Space.jpg" />
Any idea what might be causing this? I tried to look at the documentation for Request.Path and Request.Url, but I can't figure out why they would be different. Hitting the Request URL directly brings up the resource correctly.
Update: I managed to get a trace of one of the malfunctioning requests by using IIS 7.0's Failed Request Tracing feature:
Referer: Google search
User-Agent: Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3
RequestURL: http://www.somesite.com:80/Images/Image%20With%20Space.jpg
Typing the URL manually into my iOS 5.1.1 brings up the image correctly. Searching for the image in Google Images brings up the image correctly. Still no successful reproduction.
Partway down the trace I see:
MODULE_SET_RESPONSE_ERROR_STATUS Warning. ModuleName="RequestFilteringModule", Notification="BEGIN_REQUEST", HttpStatus="404", HttpReason="Not Found", HttpSubStatus="11",
According to IIS' documentation, 404.11 from the Request Filtering module is a "double encoding" error in the URL. Experimenting a bit, if I purposefully create a double encoded url such as http://www.somesite.com/Images/Image%2520With%2520Space.jpg I get the exact error in the event log, complete with malformed Request Path.
The malformed Request Path in the event log error appears to be a bug in ASP.NET 4.0.
It doesn't, however, explain why I'm getting the error in the first place. I checked a large number of failed request logs - the only common factor is that they're all using AppleWebKit. Could it be a bug in Safari?
The httpRuntime section of the Web.Config can be modified to adjust the URL validation. ASP MVC projects are usually running in the validation mode 2.0 and the default invalid characters (separated by commas) are listed below.
<httpRuntime requestValidationMode="2.0" requestPathInvalidCharacters="<,>,*,%,:,&,\" />
As you can see the % sign is considered invalid. A space can be encoded to %20 causing the validation error. You can just add the requestPathInvalidCharacters attribute to the httpRuntime section in your Web.Config file and copy the values I listed below except for the "%," part.
Scott Hanselman has a blog post about this issue:
http://www.hanselman.com/blog/ExperimentsInWackinessAllowingPercentsAnglebracketsAndOtherNaughtyThingsInTheASPNETIISRequestURL.aspx
I can't help thinking that - given the restricted user-agent - this might represent incorrect handling of the URL by that browser on IOS 5.1.1. I don't personally own such a device so I can't test this - but it would be interesting to investigate how it behaves with a url that actually has spaces in it instead.
I have a feeling that it's seeing the %20 in the url from the page source and double-encoding it, thinking it's being helpful. The problem there being that IIS will decode it back (before ASP.net kicks in) and throw it's rattle out of it's pram because now it sees a literal %20 instead of a space.
I personally don't recommend modifying your servers' security settings; however it would be the easiest solution so I dare say that's what you will do.
Rather, I think if you can confirm this 'bug' (I'm already on the road, finding a safe hiding place from Apple's lawyers), find a format that works for this device; or take all the spaces out of your resource urls. A - is the best alternative.
Related
I have my website hosted on IIS with window 2016 OS. When I am going to disable the Form Authentication under IIS, it is giving me the following error.
Form Authentication.
Exception from HRESULT: 0xC00CEF03
i had a similar issue but it occurred when i was trying to disable the 'Machine key' - 'automatically generate at runtime' and then Applying the same.
For your error, please verify if the authentication is enabled/disabled for Default Web-site. Change that setting and then try disabling you specific websites status. It should ideally work.
I've seen this error stem from three different controls on the authentication method:
If configuring the authentication method on an application, and the authentication method you're trying to disable is enabled on the containing site.
If configuring the authentication method on a site, and the authentication method you're trying to disable is enabled on the Default Web Site.
If configuring the authentication method that has been defined in a web.config file. You should adjust it in the config file.
0xC00CEF03 error code translates to WR_E_NSPREFIXWITHEMPTYNSURI which refers to “Writer: cannot use prefix with empty namespace URI” (Reference).
This error occurs when there is something wrong with the web.config file. It’s probably corrupted or there are incompatible tags and parameters. As a result of this corruption and incompatibility, IIS is not able to read this file. Therefore, it can’t make a change.
The issue mostly happens after migration because a piece of configuration that works in the older version of IIS (and .NET Framework) probably became unsupported in the newer version.
The shortest way of finding what part of the web.config is causing the issue is to remove sections one by one and test. High-level steps:
Remove a section from the bottom of the file (Let’s say you removed system.serviceModel section)
If the issue goes away, add the section back and start removing the subsections of it one by one. (For example, ws2007HttpBinding subsection in system.serviceModel section)
If the issue goes away again, bring the subsection back and go through each lines. Prefixes like wsid:, asm:, and trust: are the most common causes of this issue
Source: 0xC00CEF03 error (Cannot use prefix with empty namespace URI)
Currently, we are adding asp-net web api support to an asp.net application. However when using any path to request an action on the controller, AppRelativeCurrentExecutionFilePath is always set to "~/" and results in 400 error. Used the route debugger available here confirmed that AppRelativeCurrentExecutionFilePath is always incorrect no matter what the url is.
For e.g. all of below url accesses, has AppRelativeCurrentExecutionFilePath as "~/"
http://localhost:1521/Testclient/apitest/values/get
http://localhost:1521/Testclient/apitest/values/get/1
Route debugger also shows failed/no match for above urls even though route table has required entries.
Have disabled all Application_BeginRequest/VPP/module/http handlers and anything that can cause routing to be impacted but still getting into same issue. Any other possible ways this can be debugged?
Update1: Checked the application.Request.AppRelativeCurrentExecutionFilePath by handling Application_BeginRequest( ) in global.asax, even there it appears to be wrong.
Seems to have found the issue, site had a "." in the name and for some reason asp.net does not like it. Root path that caused the issue was
http://localhost:1521/Test.client/apitest/values/get
http://localhost:1521/Test.client/apitest/values/get/1
Note the "Test.Client", changed it to "TestClient" and all worked as expected. When i copied the link from the test machine, had changed it and overlooked it. This should save somebody few hours if they hit this problem. Still not sure if this is a bug!?
Sometimes I come across an image that I can't scrape so that it can be saved. An example of this is:
https://s3.amazonaws.com/plumdistrict.com-production/perks/12321/image/original.?1325898487
When I hit the url from Internet Explorer I see the image but when I try to get it from the code below I get the following error message "System.Net.WebException The remote server returned an error: (403) Forbidden" error with GetResponse:
string url = "https://s3.amazonaws.com/plumdistrict.com-production/perks/12321/image/original.?1325898487";
WebRequest request = WebRequest.Create(url);
WebResponse response = request.GetResponse();
Any ideas on how to get this image?
Edit:
I am able to get to save images that do have extensions. For example I can scrape the following image just fine:
https://s3.amazonaws.com/plumdistrict.com-production/perks/12659/image/original.jpg?1326828951
Although HTTP is originally supposed to be stateless, there are a lot of implementations that rely on it being stateless. I could configure my webserver to only accept requests for "http://mydomain.com/sexy_avatar.jpg" if you provide a cookie proving you were logged in. If not, I send you a redirect 303 to "http://mydomain.com/avatar_for_public_use.jpg".
Amazon could be doing the same. Try to load the web page using Chrome, and look at the Network view in developer mode (CTRL+SHIFT+J) to see all headers supplied to the website. Maybe you even need to do a full navigation in the same session before you are allowed to see the image. This is certainly the case in many web applications I have developed :-)
Well, it looks like it's being generated from a script (possibly being retrieved from a database). The server should be sending a file/content type to go along with that... but it doesn't seem to be, which I believe is a violation of standards.
My Linux box knows full well that that's a JPEG image once it's on my hard drive, because it examines file headers rather than relying on extensions. Perhaps there is a tool to do the same in Windows?
Edit: Actually, on further contemplation, it seems odd that you'd get a 403 for that. Perhaps the server is actually blocking you from retrieving the file in that manner.
It's the first time I am doing something with headers. I am mainly concerned with Cache-Control but there may be others I will need to check as well. For example, I try to send the following header to the browser (based on tutorials I just read):
Cache-Control:private, max-age=2011-12-30 11:40:56
Google Chrome displays it this way in Network -> Headers -> Response headers, but how do I know if it's correct, that there aren't any typos, syntax errors and such? Will it really work? Will the browser behave like I want it to, or will it treat it like a gibberish (something like "unknown header/value")? I've tried sending nonsensical headers on purpose but they got displayed with the rest. Is there any Chrome tool / addon for that, or any other way? Thank you in advance!
I'm afraid you won't be able to check if the resource has been cached by proxies en route, but you can check if your browser has cached it.
While in the Network panel of Chrome DevTools, hit F5 to reload your page. You should see something like "304 Not Modified" in the status field for the resource you are treating (which means the resource has not been modified and its contents were not received from the server but rather loaded from the browser's cache.)
The folk in the QA department use visual studio team test (2008 IIRC) to run load tests against our web application.
The latest set of tests have failed on several pages. The error reported is
Request failed: The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF
Searching for this using google yields quite a few results. it would appear that this error message is generated from the .Net framework WebRequest class (i.e. it is not a visual studio specific message). The most useful result is this one, which details my exact problem and how to suppress the error.
But of course, I want to get to the bottom of why this error occurs in the first place. Here are some more facts: -
This error never used to occur when the tests were run against an older version of the web app. The web app. host OS and web server (Win 2003 and IIS 6) are identical in both cases.
Not all the pages generate this error - only some.
The only significant change to these pages (that I can think of) is that they now use some AJAX whereas before they did not (IIRC)
In order to narrow down the problem, I created the simplest page that I could to replicate the problem. Luckily, that was not too hard. I then inspected the bytes in the header using Fiddler but I could not find an occurrence of a CR (0x0D) that was not followed by a LF (0x0A).
The raw HTTP response (as stored from Fiddler by response saving bytes - so its encoding should not have been altered during the save) is here as text if you don't believe me!
So now I am left thinking that the supposed error might be a false alarm. Does anyone else have experience of this/can help shed light?
This is definitely not a false alarm - I've been getting this error in my app a lot while trying to communicate with Facebook API.
I've just stumbled upon this response from Steven Cheng - http://www.velocityreviews.com/forums/t302174-why-do-i-get-the-server-committed-a-protocol-violation.html - and let me quote him:
From your description, you're using
the HttpWebRequest component to send
some http request to some external web
resource in your ASP.NET web
application. However, you're always
getting the "The server committed a
protocol violation.
Section=ResponseStatusLine" error
unless you set the following section
in the web.config file:
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true" />
</settings>
</system.net>
And you're wondering the cause of this behavior, correct?
As for this issue, I've performed some
research on this and found that the
problem is actually caused by the
critical http header
parsing/validating of the
HttpWebRequest component. According to
the Http Specification(http1.1), the
HTTP header keys shoud specifically
not include any spaces in their names.
However, some web servers do not fully
respect standards they're meant to.
Applications running on the Dotnet
framework and making heavy use of http
requests usually use the
httpWebRequest class, which
encapsulates everything a web oriented
developer could dream of. With all the
recently issues related to security,
the "httpWebRequest" class provides a
self protection mechanism preventing
it to accept HTTP answers which not
fully qualify to the specifications.
The common case is having a space in
the "content-length" header key. The
server actually returns a "content
length" key, which, assuming no spaces
are allowed, is considered as an
attack vector (HTTP response split
attack), thus, triggering a "HTTP
protocol violation error" exception.
Will try if this helps right now and post results later