ITextSharp saying File not found when published to My server
I was getting 404 errors for some long URLs on a website I'm developing. After a bit of digging I discovered that this occurs when the length of certain aspects of the URL exceed configurable limits in IIS7. In this case the maxQueryString attribute of the requestLimits property needed to be increased in the web.config
<system.webServer> <security> <requestFiltering> <requestLimits maxQueryString="4096" maxAllowedContentLength="4096" maxUrl="8192" > </requestLimits> </requestFiltering> </security>
This fixed the problem instantly on my development server but on the remote server I now get:
500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.
And that's all the information it gives me.
1:Browser prompting download of JSON response, ASP.NET MVC2Entity framework demo projecthow to select a radio button by default - asp.net mvc strongly typed html helpers
2:Should We Instantiate Data Context & Repository In Controller?
Are you sure your hoster/production-server is running Windows Server 2008 (or 2008 R2)? The settings you are describing above are only valid for IIS 7+..
You should not use such long URLs. Among another reasons, at least one of the common toolbars (Bing, Yahoo, Google) will break them, producing just such errors. Users will blame you.. I know this for the reason this one of my users was having just such a problem with a legacy app. When I removed the toolbars (she had all three installed!), the problem went away..
A GET request is only limited by a browser's limit on the length of the URL string. In IE it is 2,083 characters, minus the number of characters in the actual path. Other browsers did not have a clearly defined limit on the length of the URL string. These articles might be helpful to you.. http://www.boutell.com/newfaq/misc/urllength.html
. RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1," does not specify any requirement for URL length, so browsers are free to stipulate what they deem fit.. therefore you should use POST instead of GET if it's fits within your requirements.