I have a WCF REST interface with UriTemplate="Action/{object}". This interface works fine on IIS, but on the ASP.NET development host, it is giving me 405, e.g., The HTTP verb POST used to access path '/x.svc/Action/a.b.c' is not allowed. In the debugger, I reach Application_BeginRequest before it fails.
I don't have an issue for {object} values that don't contain a dot.
From what I've found, it appears this is a conflict with routing rules. It is as if the UriTemplate is conflicting with a higher priority rule that looks at the URI as a file path.
Is there a way to get the ASP.NET Development Server to behave the same as IIS?
Is there a way to get the ASP.NET Development Server to behave the same as IIS?
You could use IIS Express instead of Cassini. It will behave exactly the same as the full blown IIS server. You might need to move all your http modules and handlers to the <system.webServer> section if you switch to IIS express.
Related
I need some help. How can I to stop my ASP.NET Core application from redirecting to HTTPS?
Currently, when I enter e.g.,
http://www.homeautomationinternal.xyz/
It redirects to
https://www.homeautomationinternal.xyz/
There can be several possibilities why your ASP.NET Core application redirects your requests from HTTP to HTTPS. The two most common root causes are the following registration calls:
app.UseHttpsRedirection()
app.UseHttps()
The former enforces temporary redirection, while the latter one indicates permanent. These calls are generated into your Startup in most cases by default. But there are project types where you can define whether or not to Configure for HTTPS. (Visual Studio provides this opt-out functionality). For further information please check the following MSDN security article.
Other middlewares like Url rewrite can also cause redirection, but this has to be explicitly registered. It is not added by default to your Startup's Configure method. Even reverse proxies (like IIS) can do that on your behalf.
I have created a wcf web service. When i run it for http it works fine and gives result in wcftestclient as well as browser.
But when i test for https by changing it fot https it gives result in wcftestclient but when i try to call method from url by passing parameters. i receive error.
HTTP 400 error
It’s not you, it’s this link (it appears to be broken).
I have changed configuration file for https. It is working in wcftestclient but not in browser. it gives wsdl file but error for method calling.
I call method as
https://my-pc/Service.svc/LogIn?a;a
Quick way is Goto project properties of your WCF Service Project in Visual studio, open Web tab/page and make sure IIS web server is selected and IIS Express not selected mention your web address like https://localhost/WcfService1 and if virtual directory is not created then Click on "Create Virtual Directory Button", visual studio will create with required SSL settings for you.
To verify open Internet Information Manager(inetmgr), select service virtual directory/website and verify binding in Actions pane on the right hand side.
It should have two browse links under Manage Application heading one for HTTP and one for HTTPS.
Hope this helps.
Has anyone been able to get the MVC mini profiler working on IIS 6? I've set up the profiler in my application and it works perfectly in Visual Studio, IIS Express and IIS 7.5 but when I put the exact same application onto IIS 6 it won't work.
The problem seems to be around loading /mini-profiler-includes.js, I just get a 404 response. I've checked the route table and the correct routes have been registered by the profiler but apart from that I'm not sure what else to try.
On IIS 7, ASP.NET by default runs in integrated mode so the ASP.NET runtime will handle all requests, however on IIS 6 ASP.NET only handles extensions explicitly listed in the mappings section.
When the request comes in for /mini-profiler-includes.js IIS sees the .js and tries to serve the static file but as the file is "generated" by ASP.NET the handler never gets hit and a 404 error is returned.
In order to fix this you need to add a wildcard mapping to IIS so all requests get handed to ASP.NET. This blog post has a good walkthrough of the process.
I wonder if you could help me with this. I have a .NET 3.5 WCF RESTful service that returns json. Service works fine on my local machine but when I deploy it on IIS6 I get this error: The server encountered an error processing the request. See server logs for more details.
The WebInvoke method is GET and when I try to access the service method in browser on the IIS6 machine I get a prompt that asks me to download a file (with the response of the GET request).
I'm really baffled by this as when I choose to download and open the file I see the json that is suppossed to be returned....Strange behavior by IIS.
Any clues on this?
The answer was rather trivial...
Because my wcf operation was returning a List of objects for some reason IIS insists in that case the BodyStyle to be WebMessageBodyStyle.Wrapped , unlike local development service where the response was returned correctly both with Bare and Wrapped formats.
Thanks for all suggestions guys.
If I have a WCF SOAP (C#) based web service running in my local IIS - and I make an ASP.net website, again running in my local IIS - will the javascript making HTTP request calls from my webpage be successful? Or do the same origin policy rules come into play here?
It depends on how your sites are configured in IIS. Check out this wikipedia article on same origin policy.
Let's say your WCF SOAP service is running on http://localhost/service/GetStuff.svc and your ASP.NET site is running on http://localhost/mysite/Default.aspx. According to the table in the same origin article, the call should succeed, since your server host is the same in both cases (localhost) and differ only on the directory being referenced.
But, if your WCF SOAP service is running on http://localhost:8080/service/GetStuff.svc and your ASP.NET site is running on http://localhost/mysite/Default.aspx (default port of 80), then the call will fail since the server host differs in the port being accessed.
The three things to consider are host, protocol (http or https) and port. According to the article, not all browsers enforce port.
I hope this helps. Good luck!
BTW, does your application work?