We have a WCF service in our web application which is being called by browser through ajax(jquery and asp.net scriptmanager)
In this service some of the methods are WebGet and some of them are WebInvoke
Problem is now any request to WebInvoke method through asp.net scriptmanager is making request using http 'OPTIONS' instead of 'POST'. And webserver is going to deny this request as it don't allow OPTIONS
POST should be default for WebInvoke attribute when no method is defined.
We started having this problem since last couple of weeks just spotted today. We upgraded everything to .net 4.0 around same time so not sure .net 4.0 has something changed.
Also weird thing is everything works fine when using website like xyz.com we only see problem when using www.xyz.com
Any idea what it could be?
Edit: Ok got little closure
Problem is Asp.net scriptmanager does not allow cross site reference in ajax.
But wait we do not do anything that calls cross site.
What i found is when i use www.a.com some how js files generated by script manager wants to use a.com not www.a.com.
Any idea how to resolve this?
Related
OK, co I have searched and tried what I think is everything. Basically I have an app I have built in Sencha Architect that uses a JSON proxy to call a Get method in my Web API. Running local host, not a problem, deploy to live, not a problem. Run localhost against live web api.. PROBLEM! :)
So, have spent the last couple of hours reading up on CORS and implementing Access Allow Origin in response header, even allowing "OPTIONS" in response header as part of the "pre-flight" check before trying to make the call and still no go. I have set request headers just in case in my call, but convinced this is not the actual issue. I get a 405 method not allowed, no matter what I do.
The crazy thing is, I just wanted to bundle this up as a native app and see if it worked... How does anyone else make a call to a public service using ASP.Net and IIS7.5 +?
Move your sencha app folder in asp.net project folder and run sencha app using IIS server
Many hosting companies let you define which page will be shown to the user if the user goes to a page that does not exist. If you define some .aspx page then it will execute and be shown.
My question is, why not use this for routing. since I can parse the users URL and then do a server.transfer to the page I want. I checked and there is no redirect sent to the client and the http headers are HTTP/1.1 200 OK.
So, is this a good idea for servers that don't have ASP.NET 3.5 SP1 or if you are not using MVC?
Thanks
You "can" do that, but why not just create an HttpModule and handle the routing there? That's how most of the URL rewriting systems work (in actuality, it's also how the MVC routing works since global.asax is just a pre-build HttpModule with a few extras).
The big thing with relying on that kind of server handling you describe is that you really aren't in control of it, and it is a hackish mechanism... by that I mean you are taking a function of the web server that has a specific purpose and design and laying a different meaning and function on top of it... which means you now have no built in handling for an actual 404 error. Plus, the mechanism you are contemplating is harder to adapt to your purpose than just using the other options available to you.
Unless you need something special from routing, you should consider using an existing routing component such as Mod-Rewrite or one of the dozen or so other popular URL rewriters that were built before the MVC routing engine was implemented and work fine in older versions of asp.net. There are also numerous tutorials on using HttpModules, HttpHandlers, and various other techniques to do routing in asp.net webform environments.
Can anybody tell me if there is a way for me to get the domain name of my site in the Application_Start event in the global.asax?
Normally I'd just get it from Context.Request.ServerVariables["SERVER_NAME"], but this is not available. I'd ideally also like to get the URL from the request that kicked off the application.
Hmm - from answers below, it would seem that being on IIS7 makes a difference here. This is new and there are now design guidelines to try and stop you from doing it:
IIS Blog
You can access the Context through the static HttpContext.Current member.
HttpContext.Current.Request.ServerVariables["SERVER_NAME"];
HttpContext.Current.Request.Url;
Edit, Based on some of your comments I did some additional research
This error is due to a design change in the IIS7 Integrated pipeline that makes the request context unavailable in Application_Start event. When using the Classic mode (the only mode when running on previous versions of IIS), the request context used to be available, even though the Application_Start event has always been intended as a global and request-agnostic event in the application lifetime. Despite this, because ASP.NET applications were always started by the first request to the app, it used to be possible to get to the request context through the static HttpContext.Current field.
So you have two options
Change your application code to not use the request context (recommended).
Move the application to Classic mode (NOT recommended).
http://mvolo.com/iis7-integrated-mode-request-is-not-available-in-this-context-exception-in-applicationstart/
Your web-application could run under multiple different domains. Since there is no current request in the Application_Start event, you cannot know under which domain the application will be called.
You could however find out the machine-name using System.Environment.MachineName.
I'm guessing you are on IIS 7? Because the HttpContext is available there on IIS 6.0.
Can you consider filling that information later on? The first call to Application_BeginRequest for example?
In VB.NET, in Global.asax, I use the following:
Hosting.HostingEnvironment.ApplicationHost.GetSiteName
It corresponds to the application name in IIS.
UPDATE: It seems the method "GetSiteName" is not intended to be called directly and it doesn't work anymore for me in Visual Studio 2015 (or maybe it is because the framework version change I made). I fixed it by replacing it by:
System.Web.Hosting.HostingEnvironment.SiteName
Do you have access to the Request object at all? If so i think you could use
Request.Url.Authority
It will return the dns host name which is what you are looking for.
G
Have you tried: -
System.Web.HttpContext.Current.Request.ServerVariables["SERVER_NAME"]
Thanks,
Phil.
Today we tried to put an ASP.NET application I helped to develop on yet another production machine. But this time we got a very weird error.
First of all, from all the ASP.NET pages, only Login.aspx was working. The rest just show a blank screen when they should have redirected to Login.aspx. The HTTP response is 200, but no content.
Even worse - when I try to enter the address of some inexistent ASPX page, I also get HTTP 200! Or, when I enter gibberish in some existing ASPX page code (which should have been accessible without login) I also get HTTP 200.
If I enter the name of some inexistent resource (like asdasd.jpg), I get the expected 404.
The redirect to login page is written manually in Global.asax. That's because the application has to use some alternate methods of authentication as well, so I can't just use Forms Authentication. I would suspect that Global.asax is failing, if not for the working Login page.
Noteworthy facts are also that this machine is both a Domain Controller and has SharePoint installed on it. Although the website in question is listed in SharePoint's exception list.
I would check the following:
Is the application within a virtual application or its own site and not just a virtual directory?
Does the application have it's own App Pool? If it does not then is the app pool shared by apps in a different .net version.
Is the .net version of the application the correct one? 1.1 or 2.0?
Do the files in the file system have the correct permissions to be accessed via IIS?
Have you performed an IIS Reset?
Create a stand alone test.aspx page within your folder that just displays the date/time and check it works.
Make this single test.aspx page perform an exception (eg. divide by zero) and see what the outcome is.
More information required.
What Op Sys?
What mode IIS running under?
What version of .Net?
What version of SharePoint?
(Why are you using your DC as a web host?)
Does it work on the other production machines you've deployed to?
If so what is different between this machine and the working ones?
Did you deploy the same way?
Are you sure your hitting the right machine?
Are you sure your hitting the right web site?
What ISAPI components are installed globally and for the web site?
Is .aspx mapped to the ASP.Net ISAPI filter?
Do you have any HTTP Modules or HTTP Handlers configured?
Can you change the global aspx to write out some messages so you can be sure the piece of code you interested in is reaching?
Anything coming up on the IIS log or the event logs?
Addition:
What version of .Net?
By the sounds of it the .jpg request is being dealt with by IIS directly which is why you get the 404, but the .aspx request is being dealt with by something else which except for you login page, is always returning 200.
Assuming .aspx is wired correctly to .Net the the order of processing is based on ISAPI filters (high to low then global before site), then the ASP.Net ISAPI Extension (sorry I said this was a filter earlier but it's actually an extension). Then we get into the ASP.Net pipeline based on your .Net configs, and calls the HTTP Application (which includes your global.asax code), any HTTP Modules followed finally by a HTTP Handler. Your ASP.Net web forms are just fancy HTTP Handlers.
However, the request can be responded to and terminated from any point.
Since your code works on other machines though, I'm tempted to point a finger at SharePoint if it isn't installed on the working machines. Is this SharePoint 2007? That is also an ASP.Net application (I don't think 2003 was).
I was planning to use url routing for a Web Forms application. But, after reading some posts, I am not sure if it is an easy approach.
Is it better to use the URL Rewrite module for web forms? But, it is only for IIS7. Initially, there was some buzz that URL routing is totally decoupled from Asp.Net MVC and it could be used for web forms.
Would love to hear any suggestions..
This is the best article I found about this topic: IIS URL Rewriting and ASP.NET routing by Ruslan Yakushev.
IIS URL Rewriting
When a client makes a request to the Web server for a particular URL, the URL-rewriting component analyzes the requested URL and changes it to a different other URL on the same server. The URL-rewriting component runs very early in the request processing pipeline, so is able to modify the requested URL before the Web server makes a decision about which handler to use for processing the request.
ASP.NET Routing
ASP.NET routing is implemented as a managed-code module that plugs into the IIS request processing pipeline at the Resolve Cache stage (PostResolveRequestCache event) and at the Map Handler stage (PostMapRequestHandler). ASP.NET routing is configured to run for all requests made to the Web application.
Differences between URL rewriting and ASP.NET routing:
URL rewriting is used to manipulate URL paths before the request is handled by the Web server. The URL-rewriting module does not know anything about what handler will eventually process the rewritten URL. In addition, the actual request handler might not know that the URL has been rewritten.
ASP.NET routing is used to dispatch a request to a handler based on the requested URL path. As opposed to URL rewriting, the routing component knows about handlers and selects the handler that should generate a response for the requested URL. You can think of ASP.NET routing as an advanced handler-mapping mechanism.
In addition to these conceptual differences, there are some functional differences between IIS URL rewriting and ASP.NET routing:
The IIS URL-rewrite module can be used with any type of Web application, which includes ASP.NET, PHP, ASP, and static files. ASP.NET routing can be used only with .NET Framework-based Web applications.
The IIS URL-rewrite module works the same way regardless of whether integrated or classic IIS pipeline mode is used for the application pool. For ASP.NET routing, it is preferable to use integrated pipeline mode. ASP.NET routing can work in classic mode, but in that case the application URLs must include file extensions or the application must be configured to use "*" handler mapping in IIS.
The URL-rewrite module can make rewriting decisions based on domain names, HTTP headers, and server variables. By default, ASP.NET routing works only with URL paths and with the HTTP-Method header.
In addition to rewriting, the URL-rewrite module can perform HTTP redirection, issue custom status codes, and abort requests. ASP.NET routing does not perform those tasks.
The URL-rewrite module is not extensible in its current version. ASP.NET routing is fully extensible and customizable.
There's a great post here about the differences between the two from a member of the IIS team.
One caveat I would advise is that for WebForms, you need to be careful when using Routing. I've written a sample implementation of how you'd use routing with WebForms that addresses these concerns and hopefully helps answer your question.
Do you want formatted urls to be a factory for spawning pages?
or do you want to make the .aspx go away?
rewriting, is for making the .aspx go away, or just to tidy up the url.
Routing, is for looking at a request and determining which object should handle it. They sound similar, phil haack has a few good articles on the subject.
in iis6, isapiRewrite, is very good
I recently just wrote my own rewriting system to make the URLs on my sites look better. Basically, you're going to need to write your own IHttpModule and add it to your web.config to intercept incoming requests. You can then use the HttpContext.Current.RewritePath to change what you're pointing at.
You'll also want to configure your site to use the aspnet_isapi for everything.
You'll discover a lot of little problems along the way like trying to work with pages that use "tails" on them (like for PageMethods), or pathing of page elements and form postbacks, but you'll get through them.
If interested, I can post a link to the code and you can check it out. I've worked a lot of the problems out already so you can read through it as you go. I'm sure there are a lot of other people that have done this as well that might be good resources as well.
You may want to check out my answer to this question: ASP.NET - Building your own routing system. I include some good references to help build your own routing system with either using the url rewriting method or the new routing engine that you can use that came out of the ASP.NET MVC project.
The Dynamic Data project that is available with .Net 3.5 SP1 shows a good example of a url routing implementation.
For URL Rewriting on IIS, IIRF works in IIS5, 6, 7. Free. Easy. Fast. Open Source. Regular expression support.