We have one of our sites hosted externally, and all of our internet access is through a proxy.
We've found that this remote site (ASP.NET 4.0, IIS 7.5, Server 2008 R2) doesn't work on most of our domain machines due to the "Use HTTP 1.1 through proxy connections" setting not being set in IE9 - the ScriptResource.axd pages get garbled and come out as illegible characters. (WebResource.axd and all other calls are fine).
We can fix this internally, but are worried that other users may have the same problem, so my question is: is there a setting that controls how ScriptResource.axd is served by IIS that we can change to alleviate this?
I eventually found the the 64-bit ScriptResource.axd handler was sending compressed data whether the browser could handle it or not.
The fix was to add this to the web.config:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<urlCompression doDynamicCompression="false" />
</system.webServer>
Related
Recently I had to reset windows on my work laptop due to a faulty driver that caused endless bluescreens after a few minutes of booting up. I use windows 10, and had windows on its own partition so all my work was unaffected by the reset.
This is relevant because before the reset, my ASP.NET sites would run perfectly fine locally with IIS 10, I could run my API site and use Postman to do HTTP requests as expected, login to a localized version of the site, etc. All without issues. After the reset, and the subsequent reinstalling of all the programs that were present before the reset, the API site no longer works as expected. Now I get a consistent 403.14 Forbidden error on the main page, and various other errors depending on whats being done.
I need to clarify that this site is not a directory site so enabling directory browsing as most answers to this questions tell to do is not the solution I need.
I've tried dozens of solutions both on SO and elsewhere, including:
-Making sure the IIS app pool is set to v4.0 and not v2.0
-Typing this: 'C:\windows\Microsoft.NET\Framework64\v4.0.30319> aspnet_regiis.exe -i'
in CMD.
-Making sure all the required features in 'turn windows features on/off' are on.
-Putting this:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
in the config.
-Trying this alternative to the above:
<system.webServer>
<modules>
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
</modules>
-Resetting all the repositories for the sites with a hard reset in git, then cleaning and rebuilding everything
-Checking with my coworker that both of our setups are the same, including all the important files and program settings (they are, his local sites work as expected)
-Reinstalling windows again and installing all the programs with great attention to what does what and what order they're installed in.
-Testing that it all works on my personal PC (it does)
The expected result is that the home page is a blank white page, and each of the controllers accessed from there (i.e. http://localhost/api.mysite/account/login/, .../account/getinfo/,.../account/changeinfo/) all work as expected accepting and returning json. The only error messages are as follows:
403.14 when attempting to access the site through a browser to the default page (http://localhost/api.mysite/)
405 error when POST-ing to the default page with Postman, as expected(?).
404 error when trying to POST or GET to any of the controllers methods in the API site with Postman. (http://localhost/api.mysite/account/login etc.)
Any help is greatly appreciated, this is incredibly frustrating! Thank you.
We are experiencing a problem with an application we recently migrated from IIS 6 .net 2.0 to IIS 7.5 .net 4.0 (ASP.Net Web Forms)
The code performs custom rewriting in the global.asax Application_BeginRequest event and uses the HttpContext.Current.RewritePath() method to do the re-writing.
When a bad request (a page which does not exist) with an extension comes in like /kentest/test.blah things are handled properly - IIS properly passes in the custom error page which we re-direct to.
When a bad request comes in without a file extension like /kentest/test then IIS does not properly pass the custom error page. We get caught in a loop rewriting the same /kentest/test over and over until IIS throws a recursion 500 exception.
Any ideas how to solve this and get requests without extensions working?
Others seem to have encountered this issue as this blog post mentions but no solution
is provided.
Update We Solved This Issue
We needed to add the following to the web.config in the handlers section:
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
We needed to add the following to the web.config in the handlers section:
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
I've got an .ASHX handler I want to use to process an HTTP PUT to allow me to upload files to the web server--the .ASHX file actually uploaded data and sticks the file elsewhere, so it never actually touches the disk here.
I've set the web.config to allow it to handle HTTP PUT, but IIS won't pass the request to my code unless I set the ACLs on the .ASHX files themselves to be writable--Which is kinda silly, since we're not actually going to write to those files.
If I set the ACLs, it works fine, but I'd like to be able to process the file without having to set the ACLs at all (I'm sure there's an appropriate way to make IIS just pass the HTTP PUT to the .ASHX file without checking the permissions on the file itself.
This is on Win2008 R2 (actually, it's on Azure's 2008 R2, but should be the same), using .NET 4.0
401 - Unauthorized: Access is denied due to invalid credentials.
You do not have permission to view this directory or page using the credentials that you supplied.
There are several roadblocks to getting PUT (and DELETE) working with ASP.NET. Since you mention Win2008 R2 (IIS 7.5) I would check to see if the errors you are seeing mention the WebDAV module or handler.
WebDAV is enabled by default as of IIS 7.5. It will interfere with HTTP PUT and DELETE verbs on ASP.NET handlers and modules. If you're implementing a RESTful service you likely don't even utilize this functionality. Disable it via your web.config.
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
</handlers>
</system.webServer>
Some other solutions are mentioned in this forum post entitled HTTP Error 405 With ASP.Net MVC and HTTP PUT on IIS 7.5.
I wrote a tiny HttpHandler, which works beautifully on my machine. However, once it was deployed to our staging server, requesting it gave an 404. I usually prefer configuring HttpHandlers in web.config, but this apparently didn’t work on the server: I fixed it by creating an .ashx file containing just the reference to my HttpHandler.
The .ashx file:
<% # WebHandler class="MyNamespace.MyProject.MyHttpHandler" %>
The web.config setting:
<httpHandlers>
<add verb="GET" path="myhandler.ashx" type="MyNamespace.MyProject.MyHttpHandler"/>
</httpHandlers>
I assume the problem is caused by the server using a "special" port (888, don’t ask why) for the website. Can it be something else, what could I be missing?
Why am I seeing this behavior on the server? The HttpHandler runs fine on my local machine with configuration just in web.config, and here it’s also served from a “random” port, i.e. http://localhost:61229/myhandler.ashx.
It sure sounds like the web.config setting is not being found.
Is this IIS 7 by any chance? In that case make sure you're putting the handler in the <system.webServer> and its <handlers> section.
If you are using IIS7 but still want to keep your old IIS 6 config files.
By setting the Application pool to run in "Classic" mode, the handler will work again.
Not recommended, but sometimes this is a quick and good enough fix.
We are using the Intelligencia URLRewriting module for asp.net with version 2.0 of the framework and IIS6. Our URLs typically have no extension.
I understand that IIS6 cannot really deal with this situation without a blanket wildcard (which causes other problems).
However, it works! Sometimes. At other times (e.g. on one dev's machine, and on my machine when I point a different virtual directory at the app) it doesn't. By "it doesn't work" I mean the configured HttpModules never even get hit.
Can anyone explain this?
Thanks.
So it turns out what was happening was the following:
request comes in to (say) http://website/products/productid
IIS can't find this hence we get a 404
by chance we have a custom error page set up in IIS for 404s
this error page sticks the referring URL on the end of the 404 error.aspx page
so we get a redirect coming into asp.net along the lines of:
http://website/error.aspx?404;http://website/products/productid
our URLRewriting regexes were now set up in such a way that they discarded the error.aspx bit and dealt with http://website/products/productid as if it were the actual URL
so asp.net renders http://website/product.aspx?id=productid as requested!
I guess this could prove to be a useful kludge for someone, but we're moving to an isapi filter. One heads-up is that this will by default lead to a tight loop of redirects!
If you run a site using the Visual Studio development web server all requests will be handled by asp.net so your HttpModule will run.
On IIS6 this should not happen unless it is set up to forward the requests to asp.net.
Are you sure that when "it works" you aren't running under the Cassini development web server included in VS.NET ? Because extensionless wildcards do work under Cassini, which can be very confusing to say the least.
If you are using an IIS6 with ASP.net 4.0, you must specify and register the modules like this:
<system.web>
<httpModules>
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
not
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
</modules>