We recently moved to a new system and seeing an odd issue, but to preface, we are using javascript, classic asp, and asmx web services (until we can re-code).
our web services are setup in their own individual application pools on IIS 7.5. The web service in question is coded in .net 4, and the app pool is setup in .net 4 "integrated".
We have multiple customers urls hitting another domain where our web services reside.
The application uses javascript ajax calls to hit our back end asp pages.
example:
https://DomainForCustomer/CustomersPage --> executes javascript ajax --> Classic ASP Code -->
Set xmlhttp = server.Createobject("MSXML2.XMLHTTP")
xmlhttp.Open "POST",postUrl,false
xmlhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
xmlhttp.send DataToSend
where postURL = https://MainDomain/WebService/WebService.asmx/Method
I should also mention I configured the web service for GET/POST requests.
So what we are currently experiencing is short requests work fine, and fast. Longer requests (approx 5-10 minutes) never get returned to a browser.
when I setup the same web service code under the same customer site in iis it runs fine. I setup print statements to a file on the web service to see when my process finishes and can see when the data should be returned back to the browser but the website doesn't seem to receive it.
would anyone have any ideas on this or be able to point to any settings that might help.
I did look into the cross-origins stuff but that seems to pertain more to javascript, not asp (what I'm told anyways).
finally, with our current architecture, our web servers are going through a load balancer with ssl off loading, so I'm not sure if that would have anything to do with it either.
So after more testing, it was determined that our ssl offloading was not configured correctly. After changing that within our system this longer running process started working much better.
Additionally I was returning 160k + characters in my response to the browser so we added to our IIS config:
<requestLimits maxAllowedContentLength="100000000" />
I know this is more particular to our config, but I hope this helps someone else in the future.
Related
I have gone through the links mentioned below,
iis forum and HttpModules & Server.Transfer / Server.TransferRequest / RewritePath problems. but unable to catch the concept behind these transfer methods.
How are they works? And which one is preferred in different situation?
Can someone explain me TransferRequest vs Transfer methods for server side transfer in asp.net and its roles?
Thanks in advance
HttpServerUtility.Transfer Terminates execution of the current page and starts execution of provided URL.
This basically maps and executes a new ASP.NET Page (or serves a static file) corresponding to the url provided. It does this in-place in the current request pipeline, without applying new configuration to the new url, or re-running IIS modules for the new url. Because of this, its very fast, but it also prevents a lot of scenarios that are possible with TRQ.
HttpServerUtility.TransferRequest Performs an asynchronous execution of the provided URL.
This is a full IIS child request under the covers, which allows it to re-run the entire request pipeline for the new request as if it was a separate request, getting the correct configuration for it, and running all of the normal IIS modules including authentication, authorization, etc. For example, IIS will apply the authorization rules for the new url, as opposed to the previous url.
TransferRequest re-runs the entire request pipeline as if it were a separate request. This means that IIS and ASP.NET modules are re-applied; authentication and authorization rules for the new URL will be honored. Note that TransferRequest requires the integrated pipeline mode of IIS 7+, and the transfer can be to an ASP page or another resource like an XML file.
Transfer transfers execution from one ASP page to another ASP page on the server. Unlike TransferRequest, IIS and ASP.NET will NOT verify that the current user is authorized to view the resource delivered by the Transfer method. If you need to force reauthorization, and integrated pipeline mode is not an option, call Redirect instead of the Transfer method. Redirect triggers a client-side redirect so that the new request will be subjected to all authentication and authorization logic of IIS and ASP.NET.
Here is my scenario...
I'm working on a server that is http:// in Classic ASP
The company purchased a web service that verifies information, this web service is https://xxx.svc?etc
What can I do to call this service? I've tried AJAX with jQuery, I've tried XmlHTTPRequest and XDR, and I'm just about out of ideas. I'm running into the same error every time.."Access Denied" when I call "open" on my object. I've heard a few things about Same Domain policies and Cross Site Scripting, but it's 2012 now. Is there any way to accomplish this?
You are running into cross domain issues.
Setup a server side page that communicates with the webservice through the ServerXMLHttp object. Read more about this here.
You could then process the request server side or make use of JavaScript to make an AJAX request to your server side page. Since it will be on the same domain, you will not run into cross domain issues.
2 suggestions...
Have you looked at JSONP: http://en.wikipedia.org/wiki/JSONP
Or you could call the service on the server side…
I have 2 web servers and 1 ARR machine for load balancing. There is an ASP.NET application running on the web servers. The system works fine except for the client side AJAX controls. The ajax controls calls web service(asmx) requests from the server. I tracked the request from the servers with Firebug both from using the ARR machine and directly from one of the web servers. Page loads successfully from web server machine. But when i use the ARR the page loads without the ajax functionality. I checked both requests with firebug. The script files for the ajax controls downloaded successufuly. But when it comes to web service calls with POST the ARR link fails. Actually there is no 404 error or something. Just no request for the POST. Any ideas?
Thx in advance
Add cache rules for not caching asmx, ashx and axd extentions. In the IIS Manager at top level click "Application Request Routing Cache". On the actions pane click "Cache control Rules". Click "Add". Apply Rule: Always, select "cache", Host name: *, URL: *.asmx*. Add rules for *.ashx* and *.axd*. Delete all the cached items in your cache. Restart IIS...
Is it at all possible to inject a request into IIS for a page, have IIS and ASP.Net handle it as normal, but get the response as html handed back to me programmatically?
Yes, I know that I could connect to port 80 using WebRequest and WebResponse, but that becomes difficult if you are accessing the IIS server from the same physical machine (loopback security controls et al).
Basically, I want to inject the request (eg for http://example.org/MyPage.aspx) between the points at which IIS would normally talk to the browser, and the point at which it would route it to the correct ASP.Net application, and get a response back from IIS between the points at which ASP.Net/IIS applies the httpfilters and hands the html back to the browser.
I'm predominantly working with IIS7 so if there is a solution that works just for IIS7 then thats not an issue.
You could implement a custom HttpModule, which would give you access to the IIS pipeline, including the final response. However, you would still need to initiate a request to IIS to actually kick off processing. Not sure if this would work for you.
From the MSDN documentation:
An HTTP module is an assembly that is
called on every request that is made
to your application. HTTP modules are
called as part of the request pipeline
and have access to life-cycle events
throughout the request. HTTP modules
therefore let you examine incoming
requests and take action based on the
request. They also let you examine the
outgoing response and modify it.
Gave you looked into the WebCkiebt class? You can make the request and get the response HTML.
http://msdn.microsoft.com/en-us/library/system.net.webclient.downloadstring(v=VS.100).aspx
I have an HTTP Module to handle authentication from Facebook, which works fine in classic pipeline mode.
In integrated pipeline mode, however, I'm seeing an additional request pass through for the default document, which is causing the module to fail. We look at the request (from Facebook) to retrieve and validate the user accessing our app. The initial request authenticates fine, but then I see a second request, which lacks the posted form variables, and thus causes authentication to fail.
In integrated pipeline mode, an http request for "/" yields 2 AuthenticateRequests in a row:
A request where AppRelativeCurrentExecutionFilePath = "~/"
A request where AppRelativeCurrentExecutionFilePath = "~/default.aspx"
That second request loses all of the form values, so it fails to authenticate. In classic mode, that second request is the only one that happens, and it preserves the form values.
Any ideas what's going on here?
UPDATE: Here is an image of the trace from module notifications in IIS. Note that my module, FBAuth, is seeing AUTHENTICATE_REQUEST multiple times (I'd expect 2 - one for authenticate and one for postauthenticate, but I get 4).
I'm starting to believe this has something to do with module/filter configuration because I've found a (Vista) box running the same code that doesn't fire these events repeatedly - it behaves as expected. I'm working through trying to figure out what the difference could be...
Thanks!
Tom
My solution was to add the following code at the end of Application_BeginRequest:
if (Request.RawUrl.TrimEnd('/') == HostingEnvironment.ApplicationVirtualPath.TrimEnd('/'))
Server.Transfer(Request.RawUrl+"Default.aspx", true);
DefaultHttpHandler is not supported,
so applications relying on sub-classes
of DefaultHttpHandler will not be able
to serve requests If your application
uses DefaultHttpHandler or handlers
that derive from DefaultHttpHandler,
it will not function correctly. In
Integrated mode, handlers derived from
DefaultHttpHandler will not be able to
pass the request back to IIS for
processing, and instead serve the
requested resource as a static file.
Integrated mode allows ASP.NET modules
to run for all requests without
requiring the use of
DefaultHttpHandler. Workaround
Change your application to use
modules to perform request processing
for all requests, instead of using
wildcard mapping to map ASP.NET to all
requests and then using
DefaultHttpHandler derived handlers to
pass the request back to IIS.
Hmmm, or this could be the issue.
ASP.NET modules in early request
processing stages will see requests
that previously may have been rejected
by IIS prior to entering ASP.NET,
which includes modules running in
BeginRequest seeing anonymous requests
for resources that require
authentication ASP.NET modules can run
in any pipeline stages that are
available to native IIS modules.
Because of this, requests that
previously may have been rejected in
the authentication stage (such as
anonymous requests for resources that
require authentication) or other
stages prior to entering ASP.NET may
run ASP.NET modules. This behavior is
by design in order to enable ASP.NET
modules to extend IIS in all request
processing stages. Workaround
Change application code to avoid
any application-specific problems that
arise from seeing requests that may be
rejected later on during request
processing. This may involve changing
modules to subscribe to pipeline
events that are raised later during
request processing.
http://learn.iis.net/page.aspx/381/aspnet-20-breaking-changes-on-iis-70/