Link to home
Start Free TrialLog in
Avatar of andculture
andculture

asked on

POST data lost when submitting from a Custom 404 page in IIS 6.0...reason?

I built a Custom 404 CMS system in .NET 3.5, and while posting data works locally in IIS 5.1 and 6.0, it does not work on the production IIS 6.0 box.  I compared the IIS 6.0 site settings item by item, and they are nearly identical, with the only differences not mattering.

The URLs for my pages are setup like "http://domain/folder/folder/page" and to avoid 405 errors (since posting to a item without an extension isn't allowed by default) I redirect to a .resource page such as "http://domain/folder/folder/page.resource".  I created this in IIS with these settings:

IIS > Website > Properties > Home Directory tab > Configuration button > Add
Executable: C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
Extension: .resource
Limit to: GET, HEAD, POST
Script Engine: Yes
Check that file exists: Yes

I verified that the form is POST-ing to "http://domain/folder/folder/page.resource" and that no redirects occur when submitted (I was throwing exceptions to make sure).  Some debug info by server:

IIS 5.1 (my computer, works):
ServerVariables["REQUEST_METHOD"]="POST"
Request.TotalBytes = 1600
Request.QueryString.Count = 1 (contains "404;http://domain:80/folder/folder/page.resource")
Request.Form.Count = 109

IIS 6.0 (test server, works):
ServerVariables["REQUEST_METHOD"]="GET"
Request.TotalBytes = 1600
Request.QueryString.Count = 1 (contains "404;http://domain:80/folder/folder/page.resource")
Request.Form.Count = 109

IIS 6.0 (product server, does not work):
ServerVariables["REQUEST_METHOD"]="GET"
Request.TotalBytes = 0
Request.QueryString.Count = 1 (contains "404;http://domain:80/folder/folder/page.resource")
Request.Form.Count = 0

Does anyone have any ideas?  I have read about POST data not being submitted in IIS 7.0, but not in 6.0.
Avatar of cj_1969
cj_1969
Flag of United States of America image

You keep referencing POST data but on your test and production server you are reporting it as a GET.
I don't know that this matters as the test server is working but these are 2 different methods and if you are coding specifically around a POST procedure then you could run into problems with this.
Avatar of andculture
andculture

ASKER

All 3 forms are setup with a method of POST, but in IIS 6.0 that POST is somehow viewed as a GET when reading ServerVariables["REQUEST_METHOD"].  As I listed above, even though the development 6.0 server thinks it is GET data, it still loads 109 values into the Request.Form.  Thanks for clarifying.

(I am using SVN to ensure that all page setups and frameworks are identical.)
<form id="GolfRegistration" name="GolfRegistration" method="POST" action="/folder/folder/page.resource" onSubmit="return CalculateAmount();">
<input type="button" value="Submit" onClick="if(testAction()){submit(GolfRegistration);}">
</form>

Open in new window

I still haven't found resolution to this problem (or even why IIS 6.0 believes the POST is a GET).  Any experts out there? ;)
Try changing the syntax of your submit statement.
What you have might be working but the correct syntax is:
document.form.submit()

Depending on the patching on the systems, they might have changed something that is making your current syntax not work.

Older versions of IIS, being less secure, are more likely to allow less tightly controlled code to work also.
Using "document.GolfRegistration.submit();" did not change the result on the production server; posted data is still lost.
If this is a custom application extension that you are using for a single purpose, what about removing the GET from Extension definition.

From what I have read, GET and POST pass the data from the page to the server in different formats.
Based on the code you have working, you have coded for a POST action where the variables and values are obtained in a specific manner.  My guess is that the browser IS doing a GET when it sends the data which is making the data unavailable to the calls you have in your code.

Based on that we need to get the page to do the submission using a POST and my guess is the problem should be resolved.
I removed the GET so that the .resource extension is setup to limit to HEAD and POST.  This did *not* make a difference when submitting on the production IIS 6.0 server.  Remember, this *is* working on our test IIS 6.0 server.

I decided to drop the "HEAD" also, and this also gave the same result on prod/test IIS 6.0.  I then completely removed the .resource extension mapping and it still worked the same.  It turns out that only IIS 5.1 needs this mapping, and it needs it for both GET and POST since that form submits to itself.
I never found a solution and had to write a file with the 404 code in it to the location with the form.  If I find an actual solution I will post it here.
ASKER CERTIFIED SOLUTION
Avatar of jbeallva
jbeallva

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
On Tuesday I will have to see if I can get anything from Request.InputStream.  Thanks for the input, and yes, I am confused too as to why IIS 6.0 worked in one case and not another.
One thought ... if this is an IIS 6 specific issue you could try running the site under IIS 5 isolation mode. Maybe this will get the feature back again.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I thought isolation mode was on a per server/site basis ... or is the client hosting multiple sites under one server/site using host headers or something.
Unfortunately isolation mode is per server, not per site.

http://msdn.microsoft.com/en-us/library/ms524990.aspx

"IIS 6.0 cannot run both application isolation modes simultaneously. Therefore, it is not possible to run some Web applications in worker process isolation mode and others in IIS 5.0 isolation mode on the same IIS 6.0 server. If you have applications that require separate modes, you must run them on separate computers."
This question was answered, although the answer isn't the one that the submitter wanted, I'm sure.  I answered in my my post at 05/22/09 11:24 AM, ID: 24453786.

The answer is, "this is by design."  IIS 6 and 7 will not let you process POST data in a 404 handler.

While not the answer that the submitter was looking for, it is valid information that may help someone else in a similar situation--better to know that something works a certain way (even if it's not the way you want) than waste time trying to accomplish something that will not work.
Comments  24453786 and 24474595 address this issue.
http:#24453786
http:#24474595