I have recently encountered an issue with some of the javascript requests are hanging in the RequestAcquireState inside IIS worker process request listing grid. In the application, I am bundling the scripts and style sheets, with Cdn=True, EnableOptimization=True and Compilation debug = false in the hosts config.
Now, with CDN = true, I initially thought when using the below:
#Scripts.RenderFormat("<script src=\"{0}\" type=\"text/javascript\"></script>", "~/bundles/vendor/kendo/js")
The request will be made from the browser to CDN (https://www.jsdelivr.com/) in this case. However, it is hitting our host.
So just wandering the how Scripts.RenderFormat internally works?
Does it make a request via IIS to grab content from the CDN and then sends it to the browser?
Is Scripts.RenderFormat tying to access a session?
Any solution to these requests donot lock on RequestAcquireState state
Image from the IIS is attached below:
Click here to see IIS request log
Thanks
Related
I have an asp.net application deployed on IIS Server located at 10.0.0.74, when
i tried to access it with chrome browser i get an empty or blank webpage.
However if my colleague tries to access it from his computer he get normal webpage with content on it.
It seems really weird to me what might be the problem.
The screen shot below is what the page looks like.
I would appreciate any help
This is not enough to go on, assuming ASP MVC 5 on IIS here are some suggestions.
On your server
Check the following
Is the physical path in IIS correct - actually point to your code?
Do you have any rewrite rules in your web.config that could be redirecting?
Did you set up the bindings correctly?
Are you hitting the site under https / http?
Checked "Turn windows features on/off" and see if ASP.NET 4.8 installed
Did you setup the HTTP Redirection and HTTP Errors
See how you are setting up error handling setup in your global.asax, see here and disable it
Goto your Control panel > Programs and features > Turn Windows features on or off and under "World Wide Web Services" / components:
Common HTTP features:
Default document
Directory browsing
HTTP Errors
HTTP Redirection
Static Content
Security
Basic authentication
Request filtering
URL Authorization
Windows authentication
The problem was that the plugins in "Content" folder were not included in the projects.
I included all the files shown in the image below.
I apologize for wasting your time, i should have checked the console before!
Problem:
We have a website written in ASP.NET hosted on an IIS server.
We want to start developing a new website using Java, Springboot, and AngularJS and want to deploy on a web server on the same machine (most probable apache tomcat).
For certain DOM elements on the ASP.NET website, after clicking on them I should be routed to the appropriate web page on the new website hosted on the tomcat.
How can we achieve this communication between these two websites?
If your DOM element is a link (the HTML anchor tag) you can just put the new website page's link as the href property and will just work. You can pass parameters in the query string.
If you are trying to submit a form on the ASP.net page to an end point on Tomcat, then use the Tomcat endpoint as the action property of form. Here you have an option of choosing GET/POST as the method.
If you are tyring to do Ajax requests from the ASP.net page to a Tomcat endpoint, you will get into a CORS issue. There are plenty of articles/tutorials on how to add a CORS header on Tomcat-SpringBoot that will help you out.
I'm running my ASP.NET MVC app on a Windows Server using IIS 10.
I've set bunch of custom header in HTTP Response Headers section for this website.
After some time I was stunned after finding out that they're no longer there.
I suspect that they were erased when I deployed a new app version - effectively by changing app path in Basic settings section for a website.
How can I make those headers persistant?
Why where they cleared?
Is there anything else that I should know about?
If custom headers were added through the IIS server interface the changes would be persisted on the web.config of the app on the server. Upon deploying a new version of the app the same would be replaced with new config file. Over writing of the config file would lead to loss of any custom configuration the old file may have including the custom header fields. With the amount of information available, I assume this may be one of the possible reason.
If you set HTTP Response Headers in iis, then you can view it in web.config.
Then you only need to monitor who cleared the HTTP Response Headers.
About how to monitor the web.config file, you can try to use the Win32 function ReadDirectoryChangesW.
Asp.net uses the Win32 function ReadDirectoryChangesW to monitor directories and files. Once a change is detected, the Application domain is recycled which may cause performance issues.
More information about ReadDirectoryChangesW function you can refer to this link:
ReadDirectoryChangesW function
I have a fairly detailed problem with which I hope someone can help. Basically, I have a .NET 4.0 website hosted on IIS7 that has some pages that necessitate URL rewriting. In order to implement these features, I have added a method to my global.asax that maps the extension-less URLs to their proper ASPX pages, and then performs a context.RewritePath in order to display the correct page.
Initially, I called this method from application_BeginRequest. However, we have some business necessary logging that occurs when Session_Start is called, and it appears that this logging is not always happening since the implementation of the URL rewriting in application_BeginRequest - Basically, every session gets logged in the DB, and after initial deployment of the URL rewriting, our session logs have dropped by about 20%, with no corresponding errors in the application log. At the same time, our IIS logs seem to be showing a relatively unchanged amount of traffic, so to my eyes, it appears that the sessions are not instantiating properly.
As a workaround for this issue, I moved the URL rewriting from application_BeginRequest to application_AcquireRequestState, so that this code won't fire until after I'm (mostly) sure that the Session has started. This works in my local dev environment and on our staging server (Windows Server 2008 - IIS 7 - .NET 4.5 Framework installed). In the Production environment (Windows Server 2008 - IIS 7 - .NET 4.5 Framework), I get 404 errors when trying to browse to the extension-less URL to be re-written.
I'm completely stumped - I've verified that I'm using the Integrated app pool, my web.config has the "runAllManagedModulesForAllRequests=true" attribute, my IIS features include HTTP redirection and static file compression, but nothing appears to be working. There's a hack that I found for using the Classic app pool, and creating extra script map handlers to handle wildcard URLs with no extensions, but I'm hesitant to put that in place in production.
Any help you can provide would be greatly appreciated. Thank you!
I would concentrate on why there was a 20% drop in session logs. Are you sure there wasn't also a drop in traffic? Are you using redirects for people coming to your site using the old .aspx Urls? Perhaps you received more 404 traffic that would not trigger the Session_Start? Did Google Analytics confirm that traffic maintained normal levels after the UrlRewite was put into place? You could also use IIS Log Parser to filter out static files and query 200 vs 404s from the log files to get a better sense of actual traffic.
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).