We have an MVC5/Razor application that last week suddenly started acting really weird. It's hosted on a Windows Server 2008 R2 (with IIS 7.5) and the problem started after installing Windows updates last week. Up until then the application was working just fine.
Problem is that when a user submits a simple form consisting of 10 text fields, 4 text areas and a drop-down list, the server doesn't respond properly resulting in an "Error_Connection_Reset" (in Chrome) / "Page Unavailable" (in IE11).
We use POST-Redirect-GET pattern with RedirectToAction in the receiving action in the controller which would normally result in a 302 response and redirect.
The form is rendered like this:
#using (Html.BeginForm("Create", "Controller"))
{
#Html.AntiForgeryToken()
<div class="editor-fields">
#Html.EditorFor(m => m.Model)
</div>
<div class="clear-fix"></div>
<div class="submit-area">
<input type="submit" value="Submit" />
</div>
}
The action has these attributes:
[HttpPost]
[ValidateAntiForgeryToken]
[AllowAnonymous]
[ValidateInput(false)]
We also use Google Analytics and jQuery, jQuery validate, unobtrusive ajax with Optimization (minification). Most JS scripts are included with Scripts.Render.
The application works fine when we access it from inside our own domain, but since all our users need access from outside, we need to fix this error. This could suggest a DNS issue but our IT support says DNS looks just fine and hasn't been changed recently.
Here's what we've done and found out so far:
Log file in inetpub\logs\LogFiles shows multiple (between 3 and 10) POST requests all with status code 302 but no following GET request. And there really should be only one POST request and then a GET request!
Log file in %windir%\System32\LogFiles\HTTPERR shows nothing interesting, just a bunch of Timer_ConnectionIdle "errors" whenever the web site reaches it's idle timeout value (which is the default 20 minutes).
Inspected requests with Fiddler and dev tools in Chrome and IE11 and all shows the same request headers. With fiddler we get [Fiddler] ReadResponse() failed: The server did not return a complete response for this request. Server returned 0 bytes. In Chrome Dev Tools it says (failed) in the Status column.
Disabled caching and compression in IIS.
Turned CustomErrors off in web.config file
Added <modules runAllManagedModulesForAllRequests="true">in web.config
Searched Google and SO for answers but so far to no avail
Checked the recently installed updates from Windows Update regarding .NET 4.5.2 and related Knowledge Base articles but nothing that really seemed related to this problem was mentioned
Edit: Also, we enabled Failed Request Tracing but we only get failed request logs for a missing favicon.ico in inetpub\logs\FailedReqLogFiles folder
Funny thing is that if i put a check mark in "Disable cache" in Chrome Dev Tools, the application also works just fine. This could suggest that it's a caching issue which is also why we tried turning on Output Caching in the IIS.
Our next step would be to either fire up a new server (Windows 2012 and a more recent version of IIS) and install the application there or install WireShark on our current server to further investigate requests. But if anyone has experienced this behaviour and know a fix for it, we would rather just fix it for now. So, please, if anyone can help, please advice.
Since the problem only seemed to occur to users outside our domain, we started thinking that this issue might be related to our firewall so we contacted our firewall provider and they confirmed that there was an issue with the latest version of the firewall software. As it happened, the firewall software was updated same day as Windows Updates were installed on our server which probably caused a bit of confusion. After reverting to the previous version of the firewall software, the issue has disappeared and everything is working as expected again. Phew!
Related
I have a very basic Single Sign On app built on VS 2015 using MVC and Web Forms. It is supposed to be a simple proof of concept and is based on some code found here and here which are essentially the same things. I've finally gotten it all converted to use .Net 4.5 but when running it on my local server it throws a 404 with no debug information.
The 404 itself wasn't initially a surprise as I was supposed to be able to change the url to one of the secure pages (for instance /WebSecApp1) which would redirect me back to the signon page but no matter what I put as the url I get the 404.
I've also tried changing the urls in the code so that they contain the port numbers for the localhost but that doesn't work either.
It was suggested to me that the RouteConfig.cs could be the culprit but I don't see how that could be since I'm calling a single page with no parameters.
I know this is kind of lite on details but does anyone have any suggestions?
Yes this looks like a routing issue as you also thought it to be. Routing is essential for web api too .Pls see https://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-and-action-selection. Does your api request look like this
GET http://localhost:34701/api/products/1?version=1.5&details=1
You do have to mention the port in the request.
While the routing that Arathy mentioned above was partially to blame, the real problem turned out to be relatively simple. In my case simply selecting Properties->Web for each of offending pages and setting "Override application root URL" to checked fixed the whole problem.
I am trying to troubleshoot an issue that is only happening in Internet Explorer on a production server. In my Visual Studio dev environment everything works fine. On production in any browser but IE everything works fine.
It is happening during the page load of a specific page in my application. After the page load, all subsequent postbacks do not work. I get a 408 error in Fiddler.
I found this post and it must be exactly what my problem is because as soon as I added the suggested meta tags to my master page everything works fine.
<meta http-equiv="Cache-Control" content="no-store,no-cache,must-revalidate">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="-1">
Can someone give me a brief explanation of why these meta tags are needed for my site to work? I feel like something I am doing with the AJAX might be incorrect or my production IIS settings might be wrong. Or is it just IE being IE?
Which version of IE is installed, and are all patches installed?
Can you provide a network trace, or more information about the HTTP/408 in question? If Fiddler is generating the 408 as I suspect it is, the problem is related to the fact that the client promised to submit a POST body but then didn't send any bytes.
Historically, there have been a number of bugs in IE near here related to the fact that, if IE expects to get an NTLM/Negotiate authentication challenge on a request, it will deliberately omit the POST body (in violation of standards) to save bandwidth. If the server fails to send an Authentication challenge, the client then fails to submit the body and the request times out. http://blogs.msdn.com/b/ieinternals/archive/2010/11/22/internet-explorer-post-bodies-are-zero-bytes-in-length-when-authentication-challenges-are-expected.aspx
In IE10, there were additional bugs in this area that have since been fixed in patches.
As noted on the other question, this is down to session cookie handling by IE and IIS.
IIS requires that in order for a cookie-based login to remain valid, it should receive some sort of contact from the client within a certain time. Typically this might be 30 minutes.
If you tell IE that a resource at a URL is valid for an hour, or a day or forever, it may be more than 30 minutes before IE decides to re-check with the server to see if the page has changed. Instead it will used cached data.
Therefore, if you don't put appropriate cache times on your resources, and the user only looks at pages they have seen before, IE might not get in touch with the server (since it has all the data cached).
Therefore the login might timeout (408 error).
Probably the real underlying problem is you should set appropriate timeouts on your resources.
The headers/meta tags as given essentially turn off all caching - this is unnecessary and probably not what you want. If you are expecting the page to change every 5-10 minutes, you might want to put a cache timeout of 1 minute, for example. Instead consider how long IE should cache the resources for, and put that.
TL;DR: use proper cache-control headers.
I have created a custom wizard control that dynamically loads usercontrols as you progress though it. The wizard is behaving as expected in all environments (PC/MAC) and browsers I have tested however a client is reporting that she is unable to complete the wizard. What I know about the issue:
It always fails on the same wizard step for this user (not the first step)
When the user clicks on the 'next' button in the step, the controller reports that the request was not a postback request (ie. IsPostBack() == false) and displays the first page of the wizard
The client is using a Mac and is accessing the site using the latest version of Safari
If the client switches to Firefox, or even just switches the user agent in Safari to something other than Safari the problem goes away.
So the problem is that when the client reaches a certain step in the wizard and clicks 'next', instead of re-loading that step to initiate the save event, the controller is merely displaying the first step of the wizard.
The step that fails contains many different form controls including textboxes, dropdowns, checkboxes and a fileupload control. We thought that it might have something to do with invalid characters getting pasted in from Word or something similar but that seems strange seeing as the problem only appears to be happening in Safari.
No exceptions are thrown and the windows event log is not displaying any related errors/warnings.
What I am looking for is ways to diagnose this error. At the moment I've been unable to reproduce the behavior that the client is experiencing but after going on site and seeing it for myself I can verify that it is definitely a valid issue.
Update 26/10/2010:
We installed a proxy on the clients NIC in order to retrieve the requests and responses. Problem is that when running the proxy the client appears to not have to problem any more. Does this behavior make sense to anyone?
Update 27/10/2010:
After investigating the traffic on the clients machine we noticed that the response headers were including some entries related to a client side proxy and we confirmed that they are in fact running the squid proxy in their office. To rule out that it had anything to do with the problem we got them to turn if off and then try the wizard again. This time no problems were encountered! So the proxy seems to be interfering with the requests causing .NET to somehow record the POST request as a non-postback. The following lines were found in the response header of a failed request. Can anyone comment on how squid could cause the behavior we are experiencing and what we can do about it?
Via:1.0 squid-12 (squid/3.1.0.13), 1.0 ClientSiteProxy:3128 (squid/2.7.STABLE4)
X-Cache:MISS from squid-12, MISS from ClientSiteProxy
X-Cache-Lookup:MISS from ClientSiteProxy:3128
If I have to troubleshoot this, I would first take a fiddler trace (www.fiddlertool.com) on the client and see what the requests are up to. I am not sure if Fiddler works on Mac, but any HTTP Watch, Network Monitor tool should be good. The reason that I am not doubting the code is that it works very well on all the other browsers, so the code shouldn't be bad.
May be there is something in the code [like adding cookies, etc] that is messing with the specific Client's browser.
HTH,
Rahul
For Mac There's a HTTPScoop which lets you to debug http post data's....it is similar to fiddler
The problem is not solved as such but we ended up just adding an exception to the clients squid proxy to bypass our website. The problem seems proxy/IIS/Safari related but we haven't been able to track the problem down any further and the client is happy with this solution as long as the problem doesn't resurface somewhere else. I'll re-post if more information surfaces.
I am working on a site which is programmed in C# .net. It uses a CMS called ADX Studio (a decision which predates my time there) which provides a shonky form of URL Rewriting (as far as I can tell it works by assigning an aspx page as the default 404 handler in IIS).
I have an web form which lives at a rewritten URL. I edited it so that the html form's action points back to the rewritten URL:
var u = new Uri(Request.RawUrl.Split(new char[1] { ';' }).Last());
userAdminForm.Action = u.PathAndQuery;
(kind of ugly but works based on what Request.RawUrl is on these rewritten URLs).
The "pretty" URL is something like this:
http://www.site.com/admin/user/edit/
On my development box (Windows XP/ IIS 5) when I initially tried POSTing back to URLs like this I got a HTTP 405 error. I worked around this by adding a script mapping so Aspnet_isapi.dll handles all (*) requests. And everything works fine on my development machine.
I just pushed my changes to the live server (Windows Server 2003 R2 and IIS 6) and the post fails silently. The page refreshes but all of my logic (from within an IsPostBack path in the code) doesn't get hit. No errors are displayed, it just doesn't work.
If I remove my code setting the .Action of the form then the postback works but it is posting to the ugly URL corresponding to the physical location of the aspx file rather than my page.
Am I missing a simple way to make this work? I don't want to be switching URL rewriting method or anything as this is a large legacy site and is unfortunately pretty dependent on ADX Studio so I don't want to do anything that will break that.
[edited because somehow the code above lost its code highlighting]
The issue is that the page's <form> tag is referencing the "ugly" url as the action. You can resolve that by completely removing the action tag from the form. Browsers will, by default, postback to the same page, ie. the "pretty" url.
This article explains how to accomplish an "actionless" form (~ two thirds of the way down) http://msdn.microsoft.com/en-us/library/ms972974.aspx
It seems like the problem is the same as it was on IIS 5. I can get it to work by doing the following in the IIS Manager:
Right click on the relevant website and select "Properties"
Choose the "Home Directory" tab
Click "Configuration" down in the "Application settings"
Click "Insert" next to the "Wildcard application maps"
Browse to the location of aspnet_isapi.dll (in my case: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll )
Untick "Check that file exists"
Click "OK" back through the Russian doll of dialogs.
This is basically the same as the approach that I linked to in the question for IIS5. However, it's not optimal because IIS is running every request through asp (even static files). Which seems like it can only slow things down. I'd like to be able to specify that asp only needs invoking for HTTP POST requests at least.
The weird thing is that IIS5 gave a HTTP 405 error when POSTing to an extension without a registered ISAPI extension but IIS6 just fails silently. And the page is being run through IIS (I can debug with a breakpoint in the Page_Load function) but IsPostBack (and IsCrossPagePostBack) don't get correctly set. Could it be related to the view state? Is there any alternative to my solution described above?
I've come to what I think is an optimal solution for this problem. It turns out that ADXStudio CMS does use the default 404 rule to do some form of URL rewriting. This has a problem with http POST:
when IIS initially executes a custom
URL on a 404 error, it changes POST to
GET, even if the client does a POST
request.
(thanks to elite brains' blog post about setting up IIS6 and ASP.NET MVC).
Rather than creating my own HttpModule I decided instead to use Ionics Isapi Rewrite Filter to rewrite my URLs. I then set the 404 error handler in IIS to the default. And I created this IIRF.ini file to redirect all requests to the same format as the 404 handler produced:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /Default.aspx?404;http://%{HTTP_HOST}$1 [U,L]
And everything seems to work great. The advantage over my previous answer is that the rewrite code is low level and runs fast and the -f and -d switches mean that if a file actually exists it isn't re-written and so static files don't have the overhead of running through .net.
EDIT!! I should add that this site runs perfectly locally. It's only when deployed that there's this issue
ORIGINAL POST:
I have a site I just put up http://splattonet0.web704.discountasp.net/
Which loads the Index view of the Home controller just fine. However, when one clicks the links to the left, the webserver is looking for the relative paths (ie E:\web\splattonet0\htdocs\Home\AboutMe) which is incorrect, since Home folder is of course under a folder called "Views"
I've made MVC sites before and have never had this problem. I can't see any difference between this or any other site I've done.
My code in my master template for the link section is as follows:
<div id="navContainer">
<ul id="mainNav">
<li>Home</li>
<li>About Me</li>
<li>Skills</li>
<li>Resume</li>
<li>Experience</li>
<li>My Websites</li>
<li>References</li>
<li>Projects</li>
<li>Hobbies</li>
....etc
</ul>
</div>
I have the same problem with and without the preceeding foreslash in the href property. I've decided to keep it there since that is how my other sites (that work!) are styled.
Can anyone shed some light on this for me? Thanks!
FURTHER EDIT:
I have been asked to provide code from an MVC site on this server I have written and that works fine. The link code in the other site (YorkCentre) is the same style: <li>text</li>
The code:
<li>Archived News</li>
<li>Board Of Directors</li>
<li>In The Media
...
</ul>
/Home/Index should be calling the "Index" action of the "Home" controller, assuming you're using default routes. The fact that "Home" is under the "Views" folder is irrelevant for MVC.
If the code is the same in both locations, and the issue only happens in one, perhaps the answer lies not within the code. The following are some troubleshooting tips which may help, as I don't know exactly what the issue is without more information about the two environments.
What are the web server platforms for your local environment and the server environment? Are you using Visual Studio and Cassini locally, and IIS remotely? If so, which version of IIS? If not, what is the platform? In any event, is the target server configured correctly?
Check to make sure your routes are set up correctly on the target server. This is especially true if your target server runs IIS6 -- IIRC, IIS 6 needs some special configuration help to deal with the standard routing in ASP.NET MVC.
If all of the above don't help you trace this out, try to replicate it locally by creating a new MVC site and merely dropping your existing files into it. See if that succeeds or fails.
Do you have other successfully-executing ASP.NET MVC apps on that server? Check their configurations against your new site's.
I have resolved the problem! In DiscountASP I have changed the Application Pool Pipeline Mode from Classic to Integrated and that results in my views being properly rendered.