Request Length ERR_CONNECTION_RESET in MVC 4 Application on IIS 7.5 - asp.net-mvc

I am having an issue with my application using MVC 4 and IIS 7.5 getting a net::ERR_CONNECTION_RESET errror. The page request size is 4.9MB. All of the content loads but the request says that is has not finished yet, and none of my javascript is applied. I have other pages in the application that all load fine and the Javascript is applied with no issues. There seems to be something going on with this particular page.
Checking around I discovered I needed to set the MaxRequestLength and the MaxAllowedContentLength in the web.config. I set both to 8Mb, with MaxRequestLength being in KiloBytes and MaxAllowedContentLength being in Bytes. This still resulted in the same thing, I double checked in IIS to make sure that the MaxRequestLength and MaxAllowedContentLength were both being set correctly, which they were.
Next I adjusted my query to bring back a smaller amount of data and the page request size was well under 900KB and everything seemed to work fine. I kept modifying my query to bring back more results to see what was the max request size I could go to with the page loading fine. To my surprise once the page request length reached 918KB and greater the request would keep going for about 2 minutes before resulting in a net::ERR_CONNECTION_RESET errror. Keep in mind this error only shows in firebug as the page seems to display all data fine except none of the Javascript was applied.
I only discovered this issue when putting my application on the production server. Everything worked fine on localhost. I beleive this to be something going on with the server and IIS 7.5 as putting ELMAH in the application I was unable to capture any errors.
At this point I have run out of ideas and things to try. Any additional help would be great.

I had the same problem,
That error usually is 'cause there is a problem with the Database connection.
try this
FireWall permissions
If your string connection has Trusted Connection, and your user doesn't have password it can be a problem, you must set a password or change string connection for sa.
i really hope that it works

Related

Invalid hostname on mvc site - IIS 8

I have an mvc app that has been deployed to our production server. It works well under IIS 8.5 using an IP and an asigned port. But the moment I try to bind it to a subdomain the app starts showing the invalid hostname error.
Tried to see if there was something off in the applicationhost.config but the binding is in the correct format. IP:Port:Binding.
The redirection also works fine, it lands on the page, but it shows the error instead of the login page.
I have deployed sites before, but not MVC apps, and bind them to subdomains and its usually a 2 step process. I dont know what im missing here.
Edit. Here is the screen of the error. Does not say a lot.
I'm not familiar with MVC or IIS, but base on my experience with other products, you very likely need to tell IIS to preserve the Host header.
Eg. https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/modifying-http-response-headers
In order to be able to modify the HTTP Location header it is necessary to preserve the original value of the HTTP host header. The outbound rewrite rule will use the preserved value when modifying the response. To preserve the original value you will store it in a temporary server variable ORIGINAL_HOST.
You should also make yourself aware about the security vulnerabilities that can result with regard to Host headers. https://techcommunity.microsoft.com/t5/iis-support-blog/host-header-vulnerability/ba-p/1031958

Large Pages on IIS + ASP.NET MVC

I am getting some trouble with a ASP.NET MVC + IIS 7.5 page. I have a really extensive page that sometimes exceeds 15.0MB uncompressed and 1.5MB compressed.
When it happens, it looks like connection never ends. The loading icon stays forever and if I see at Developer Tools, the connection is pending, despite the entire HTML is received.
It happens at Chrome, Firefox and Internet Explorer, so I think the problem is ASP.NET or IIS.
Do I need to do something special to handle such a pages?
15MB is going to be horribly slow and unresponsive - not something your users want - however much they want to "see all published files".
I would introduce, for example, paging into your webpage so not all the files are downloaded at once.
However, if you really want a 15MB page, you may find the limits config can help.
You say that the entire HTML was provably received. How could IIS or ASP.NET be the problem then? Once the content is sent they are out of the loop.
The browser is probably the problem.
You could try setting Response.Buffer to false.
The Buffer property indicates whether to buffer page output. When page output is buffered, the server does not send a response to the client until all of the server scripts on the current page have been processed, or until the Flush or End method is called.
By default, Response.Buffer is set to true, so output will be buffered. Perhaps by feeding the response to the client as it comes the browsers will behave as you need them to.
You do need to set the value of Response.Buffer before any output is sent to the browser though.
Maybe try IIS compression?
IIS provides the following compression options:
Static files only
Dynamic application responses only
Both static files and dynamic application responses
http://technet.microsoft.com/en-us/library/cc771003%28v=ws.10%29.aspx

Request URL Too Long (20K characters) IIS 7

I have an iPad application which sends data to a .NET application. The iPad application was written by a bunch of monkeys who implemented all the requests as GET instead of POST.
The application is live now, and with the client's data is sending requests over 20k characters, which is giving me this response (using Safari, which has been tested to work with URLs of at least 80k characters):
Generic 414 Error
Instead of the detailed IIS response I would get if, say, the request exceeded the requestFiltering/maxURL value in the web.config, which looks like this:
IIS 414.14 Error
Since I am getting the generic error message instead of the IIS-specific message, it makes me think this is not due to something I can fix in configuration settings (I have maxURL set to 2 billion, just to be safe...)
I understand that the requests should be using POST, but I don't really have time to rewrite the iPad application at the moment, and all of my research has only turned up unhelpful responses which say "you should limit GET requests to 2K characters" "you should use a POST instead of a GET". If that is the only feedback you have, please don't bother answering. (For instance, I am aware of this question and it's answers.)
I need to know if I can throw in a quick workaround to make this function until I have time to do it the right way. And I'm also wondering if anyone knows about hard limitations URL lengths from either the iOS or IIS side, because I can't find any specifics.
Edit: My httpRuntime parameters are also set to accept far more than 20k characters.
I know this is an old one, but in case someone will face it like I did yesterday - setting web.config parameters didn't help me either. What I've found was this MS article: http://support.microsoft.com/kb/820129/en-us.
I've added two DWORD keys to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters:
MaxFieldLength = 65534
MaxRequestBytes = 100000
NOTE: you need to restart your server or at least HTTP service to make these keys work. After restart I've managed to send a request with query string length up to ~32k characters (don't know why only ~32k though, maybe character encoding?). So I guess this is the limit for URL lenght in Windows 2003 and up.
If you are seeing this in multiple clients, it's likely to be your server settings. In the .NET 4.0's httpRuntime section, the maximum values for both maxUrlLength and maxQueryStringLength are a 32 bit signed integer, or 2147483647.
<httpRuntime maxUrlLength="2147483647" maxQueryStringLength="2147483647" />

Strange routes shown in logs for MVC3 application

In one of my MVC3 web applications I have recently noticed some strange looking Urls in the analytics reports.
The Urls look like they have an encoded value injected into the route but seem to match the routes as if the encoded value was not there.
Normal Url
/MyWebsite/Controller/Action
Appears in the logs occasionally as
/MyWebsite/(F(B5l-uGhiwA7p6lMmAdzwc27qHH8p5Kdmy5l3ixub7-meZ315Xm-uOtFl_w8RRdki4pf_yhRysEOVZ93xPV3yxDkn5XhXaY5PLara_kiqFb8BlHDZkzqv6wHgOgMTWgUF0))/Controller/Action
I have tested this on the server and local machine and it resolves to the controller regardless of the presence of the inserted value.
They appear to follow a certain pattern so I tested using other variations
/MyWebsite/(F(anything-here))/Controller/Action
Resolves fine, I can also replace the F with any other letter
/MyWebsite/(A(anything-here))/Controller/Action
However, putting more than 1 letter or other character in place of the F does not resolve
/MyWebsite/(AB(anything-here))/Controller/Action = 404 Error
I thought it may be something to do with Cookieless sessions but the information I have found suggests that this isn't supported in MVC anyway. Does anyone know what this is, or if it is anything to worry about?
EDIT:
Turning off cookies for a local browser, I set the session state to 'Auto Detect' in IIS manager and it gave me a key in the URL that looks strikingly similar to the pattern described above.
When I try to actually log in without Cookies it doesn't seem to work, but perhaps that's another issue.
Setting IIS manager to 'Use Cookies' and accessing using a browser with cookies turned off (I used Opera with option 'Never accept cookies' in Advanced preferences) didn't seem to create the URL as before, but judging by the similarities it must at least explain why it matches the routes.
Since IIS is set to 'Use Cookies' on my server, I'm not sure why the URLs are being generated, but at least I now know what they are. Perhaps this is an attempt at Session hijacking...
This does indeed look like session data stored in the URL. It's a feature of ASP.NET and works just fine with MVC as well. Look in the IIS manager for the Session State icon of your website and it's Cookie Settings Mode is most likely set to Auto Detect. This might cause it to fall back to URI mode in case cookies are not supported.

Error 104: Connection reset by peer with ASP.NET MVC app

I'm having a problem with a MVC (1.0) app that I can't figure out at all. There's two versions of the site (live and UAT) hosted on the same server. For each version of the site, the same code is shared by multiple organisations who each have their own database (MSSQL2005) and a separate web site in IIS (7.5) (pointed to the same code).
The UAT site has an update to the code and the database that is waiting to be deployed to the live site.
One of the customers ("customer A") is getting an error "104: Connection reset by peer" when they try to log in to the UAT site. They can see the login page but when they submit their login details the connection seems to be timing out (the requests seem to take ~130s to complete).
Customer A can log in fine to the live site. The other customers don't have a problem logging into the UAT site or the live site. If I try to log in as customer A, using their login details, it all works fine from within our network, and also from outside our network.
Customer A seems to be using squid as a proxy.
I can't think what the problem could be, and I've run out of ideas of things to test. The fact that I can log in as the customer fine and other customers don't have any issues seems to eliminate the code and database as problems.
What other things could I do to try and isolate the problem?
By dumping out the request data I was able to work out that something (I'm guessing the proxy) was removing the form values from the request. This obviously meant the app didn't work properly.
However, it seems whatever was removing the form data was leaving content-length unchanged, which would explain why the client was timing out waiting for more data and the server thought it was finished.
By using https instead of http (which we were going to do anyway), the request tampering seem to have stopped.

Resources