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\F ramework\v 2.0.50727\ aspnet_isa pi.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_M ETHOD"]="P OST"
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_M ETHOD"]="G ET"
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_M ETHOD"]="G ET"
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.
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\F
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_M
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_M
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_M
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.
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_M ETHOD"]. 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.)
(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>
ASKER
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.
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.
ASKER
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.
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.
ASKER
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 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.
ASKER
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
ASKER
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."
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.
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.
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.