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.
andcultureAsked:
Who is Participating?
 
jbeallvaConnect With a Mentor Commented:
Hi JStevenson,

I had the same problem, and unfortunately, it looks like the answer is "this is a feature."

Read more here:
http://www.eggheadcafe.com/software/aspnet/32116082/custom-404-handler-unable.aspx

In summary, what is happening is:

1) Your non-existent URL is POST'd to (e.g., http://mydomain.com/somepage)
2) IIS receives the request, notes that somepage doesn't exist, and it then fires up a second request to your error handler, and the method for that request is, internally, GET.  And none of your POST data is passed along.

That leaves the question as to why you are *ever* having success on IIS 6--that has me baffled.

At any rate, read the above link for more.

Incidentally, I'm running PHP on IIS 6/Windows2003, and I discovered an interesting workaround.  While PHP does not receive the POST variables from IIS (as you would expect), PHP still has access to a raw input stream, identified by "php://input", from which it can read the *original* request body from.  This will contain the POST variables, in a raw format--I was able to use PHP's parse_str() function to get the POST variables out of that raw string.

So, it *might* be possible to do something similar in ASP.NET.  Have you tried inspecting Request.InputStream?  If my memory serves me correctly, that will give you a stream that you can read from.  Maybe it will have the raw POST data?

  -Josh
0
 
cj_1969Commented:
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.
0
 
andcultureAuthor Commented:
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

0
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

 
andcultureAuthor Commented:
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? ;)
0
 
cj_1969Commented:
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.
0
 
andcultureAuthor Commented:
Using "document.GolfRegistration.submit();" did not change the result on the production server; posted data is still lost.
0
 
cj_1969Commented:
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.
0
 
andcultureAuthor Commented:
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.
0
 
andcultureAuthor Commented:
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.
0
 
andcultureAuthor Commented:
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.
0
 
cj_1969Commented:
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.
0
 
andcultureConnect With a Mentor Author Commented:
jbeallva: Request.InputStream.Length=0, so I can not read the data that way.

cj_1969: In this case the client's server hosts about a dozen sites, only a few of which we control, so running under IIS 5 isolation mode isn't an option.

Thanks for the suggestions.
0
 
cj_1969Commented:
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.
0
 
andcultureAuthor Commented:
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."
0
 
jbeallvaCommented:
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.
0
 
jbeallvaCommented:
Comments  24453786 and 24474595 address this issue.
http:#24453786
http:#24474595
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.