I have a ASP Web API project that is being hosted over SSL. I have another ASP MVC project that makes use of the API. While debugging, I am seeing behavior where the OPTIONS requests are hanging often (but not always) and preventing the other calls from proceeding.
In the Chrome debugger, these are just shown as 'Pending'. If launch Fiddler, everything works fine. I see no errors at all, things just hang. This fails before it hits the authorization code, so I can't even set any breakpoints.
Could this be a certificate problem? Firewall?
Could you try this: adding following node in web.config.
<system.webServer>
<handlers>
<!-- your other handlers -->
<remove name="OPTIONSVerbHandler" />
</handlers>
</system.webServer>
Related
I have a site where only authorizated users can access.
I also have a custom error page if a 401.2 is raised.
I configured web.config in the following way:
<system.webServer>
<httpErrors errorMode="Custom">
<remove statusCode="401" subStatusCode="-1" />
<error statusCode="401" subStatusCode="-1"
path="ERRORS\unauthorized.html"
responseMode="File">
</error>
</httpErrors>
</system.webServer>
However when I try access to my site the following happen:
http://localhost --> the ERRORS\unauthorized.html is showed;
http://localhost/index.html --> the ERRORS\unauthorized.html is not showed and I can access the page!
I also noticed two things:
if I change the page to index.aspx the ERRORS\unauthorized.html is showed;
if I use a different statusCode, i.e., 404 the HTML page is showed.
so what am I not understanding? Where is my mistake?
P.S.
I'm using IIS 10 and .NET 4.7
What authentication are you using?
Assuming you are using Anonymous authentication at the IIS level and some kind of authentication in asp.net or system.web layer, the asp.net pipeline doesn't come into picture when you access the static files as they are handled by the static file handler. SO the authorization is not coming into picture. ALso try to configure the app pool to run in integrated mode and try, because integrated mode combines iis and asp.net pipeline, if youa are running in classic it won't
ALso to add another note on the line, 401.2 is a status responded back by the server that there is no user info being passed and client has to login, this doesn't necessarily have to deal with authorization and it is a way of authentication how servers work.
I'm using ASP.NET Core RC1 as server to host my Aurelia app. My app was working just fine but the last couple of weeks something changed so that the app does no longer load when hosted on Azure. I'm not sure if it is something I changed or if it's a change on the Azure side but I'm leaning towards the latter.
I've narrowed down the problem quite a bit. The app runs fine locally, with ASP.NET Core Kestrel server and also other servers (e.g. webpack-dev-server). I have continuous deployment setup from Visual Studio Team Services to an Azure Website. The app is published and a web.config is automatically created in my wwwroot:
<configuration>
<system.webServer>
<handlers>
<add name="httpplatformhandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" />
</handlers>
<httpPlatform processPath="%home%\site\approot\web.cmd" arguments="" stdoutLogEnabled="true" stdoutLogFile="\\?\%home%\LogFiles\stdout.log"></httpPlatform>
</system.webServer>
</configuration>
Nothing happens when I navigate to my site, e.g. http://demo.azurewebsites.net/. When looking at the console I get a 404. Once I actually got this error but I can't seem to bring it back: 502 - Web server received an invalid response while acting as a gateway or proxy server
I have index.html set as default document but it is not loading. If I enter it explicitly, the app works: http://demo.azurewebsites.net/index.html
If I remove the httpplatformhandler from the web.config, then it works as expected (index.html is loaded automatically). The same happens when I remove the web.config entirely. In these cases the MVC 6 WebAPI behind the scenes does not work at all. I assume that's just logical since I remove the platform handler.
So, why is this httpplatformhandler added? Is it necessary? Why is it created? Is there some setting in the Azure portal that I can adjust to prevent this handler to be configured like this?
I also found this link that seems to suggest that things are changing and that this httpplatformhandler is about to be replaced: Closer Look: Hosting ASP.NET Core on Azure App Service
I'm out on deep water here and any and all help is appreciated.
To get default document support with the static file server middleware you need to use app.UseFileServer() instead of app.UseStaticFiles()
My Asp.net application is hosted over Azure Cloud,
In that application I do have a Java Chat control, which has its server on Linux,
now I have created a HTTPHandler to redirect that chat request to the Linux server, but some how it doesn't work over the Cloud environment (though it works very well on web environment)
it shows the below error
Microsoft Visual Studio
Windows Azure Tools for Microsoft Visual Studio
There was an error attaching the debugger to the IIS worker process for URL 'http://127.255.0.0:82/' for role instance 'deployment16(315).Cloud.AnotherHttpHandler_IN_0'. Unable to start debugging on the web server. See help for common configuration errors. Running the web page outside of the debugger may provide further information.
Make sure the server is operating correctly. Verify there are no syntax errors in web.config by doing a Debug.Start Without Debugging. You may also want to refer to the ASP.NET and ATL Server debugging topic in the online documentation.
I have even put the Handler under System.webServer as well in the web.config file, see below code
<system.web>
<httpHandlers>
<add verb="*" path="http-bind/*"
type="HelloWorldHandler"/>
</httpHandlers>
</system.web>
<system.webServer>
<handlers>
<add verb="*" path="http-bind/*" name="HelloWorldHandler" type="HelloWorldHandler"/>
</handlers>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
I don't know what restricts it over the cloud environment.
Please take a look at this question to see how to configure httpHandlers for running in Azure.
Most importantly - remove the httpHandlers section under the system.web and leave only handlers under system.webServer. Then add also the resourceType="Unspecified" attribute to the handler declaration. This should solve your issue.
I too had same problem.
I fixed it in following way .
The Problem was my machine is 32 bit and the azure server is 64 bit.
In Order to solve the problem i only changed Enable 32 bit option in
the advance setting of application pool. And the Original code worked
out fine.
i got this help from this Link
We have one module which does internal redirection to real aspx pages. He is also in charge for directly serving cached/compressed HTML/txt/cs/js output to client.
Here is how web.config looks like for modules section:
<modules runAllManagedModulesForAllRequests="True">
<remove name="RequestInterceptor" />
<add type="Lib.Request.RequestInterceptor" name="RequestInterceptor" />
<remove name="Session" />
<add type="System.Web.SessionState.SessionStateModule" name="Session" />
</modules>
Basic authentication is turned on on IIS7. When first visitor comes to site login popup shows and he is correctly authenticated, and then pages which he visits get cached.
When next visitor comes authentication pop up doesn't show up, unless he visits a page which was not visited by previous visitor (page that is not cached). Once the cache has expired, authentication works again until the page content gets cached, and so on.
Is there a way to force authentication for every visitor? Maybe we need to add basic authentication module to module section of web.config (how to do that)?
Thanks in advance.
Cheers
While searching for an answer to a related question I came across this post:
Don't use runAllManagedModulesForAllRequests="true" when getting your MVC routing to work
It seems to be common advice to make your modules section of your
web.config say . In
fact this is quite a drastic thing to do to solve the routing problem
and has global effects that could CAUSE ERRORS. ... This highly
recommended fix can cause other problems. These problems come in the
form of making all your registered HTTP modules run on every request,
not just managed requests (e.g. .aspx). This means modules will run on
ever .jpg .gif .css .html .pdf etc.
And, while I'm not using MVC in my WCF REST Service, it did fix my (other) problem and this advice against inappropriate or overuse of runAllManagedModulesForAllRequests may be warranted.
Because httpmodule intercepts each request, server is not able to map appropriate handler for static files, dynamic files, and among others secuirty authentication.
I've got a website running under ASP .NET 2/IIS7/Vista. I have a URL rewriting module which allows me to have extensionless URLs. To get this to work I have configured the system.webServer section of the config file such that all requests are forwarded to the aspnet_isapi.dll. I have also added the URL rewrite module to the modules section and set runAllManagedModulesForAllRequests to true.
When I start up the website and visit one of the pages that uses the URL rewriting, the page is rendered correctly. However if I then visit another page the site stops working and I get a 404 not found. I also find that my breakpoint in the URL rewriting module is not getting hit. It's almost as if IIS forwards the first request to the rewriter, but subsequent ones go somewhere else - the error page mentions Notification as being MapRequestHandler and Handler as being StaticFile.
If I then make a small change to the web.config file and save it, triggering the website to restart, I can then reload the page in the browser and it all works. Then I click another link and it's broken again.
For the record, here's a couple of snippets from the config file. First, under system.web:
<httpModules>
<add name="UrlRewriteModule" type="Arcs.CoopFurniture.TelesalesWeb.UrlRewriteModule, Arcs.CoopFurniture.TelesalesWeb" />
</httpModules>
and then, under system.webServer:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRewriteModule" type="Arcs.CoopFurniture.TelesalesWeb.UrlRewriteModule, Arcs.CoopFurniture.TelesalesWeb" preCondition="managedHandler" />
</modules>
<handlers>
<add name="AspNet" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="None" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
</handlers>
<validation validateIntegratedModeConfiguration="false" />
</system.web>
The site is running under classic rather than integrated pipeline mode.
Does anyone out there have any ideas? I suspect my configuration is wrong somewhere but I can't seem to find where.
This is a bit of a long shot, but have you tried actually making the configuration changes inside of IIS?
I know that the web.config way is supposed to be 100% foolproof, but I've seen a few things where it helps to just configure it in IIS to get it working correctly.
You also may want to check out the new IIS7 rewrite module. you can read more about it here http://learn.iis.net/page.aspx/460/using-url-rewrite-module/, but chances are it will be more solid then your homegrown ISAPI filter
Try http://www.codeplex.com/urlrewriter it supports all the Apache mod_rewrite syntax and also supports Reverse Proxy.
If you're runnning in classic pipeline mode you don't need <system.webServer> section it is required for integrated mode
Enable wildcard script mapping
Open the IIS7 Manager and navigate to your site
Click on Handler Mappings
In the Action panel click on "Add Wild Card Script Map"
In the dialog point to aspnet_isapi.dll
Click Yes on the message box that asks you to confirm your mapping
In the action panel click on "View Ordered List" and move your WildcardScriptMap just before StaticFile Handler
This should bee enough.
I'm ashamed to admit this but it was a simple mistake by me :-(
In my URL rewriting module, the code to rewrite the request path was in the Init method, when it should have been inside an Application.BeginRequest handler. This explains why the rewriting worked only the first time the site was hit.
Sorry to have wasted your time people!