Classic ASP Request.Form not working when using integrated pipeline

Question

I have a large corp. web site with mixed classic asp and asp.net currently hosted with a Win 2003 server, IIS 6.

I need to modify all the pages output with some html modifications regardless the world they comes from. The asp part it's really old and badly structured, thus I can't act on any kind of "general include" to apply all the changes we need. Lastly some asp pages outputs code from multiple OCX/COM objects... We are already planning a whole rewrite/migration to .net, but unfortunately it's a long term project and I can't go for quickly.

So I was thinking (and testing) to migrate it to Win 2008 R2, IIS 7.5 and take advantage of integrated pipeline mode where I can modify all output using a .net httpmodule. Everything works fine: I can correctly "inject" html code to pages rendered via asp and asp.net, but I'm running into problems when classic asp pages are going to process form data sent via post (x-www-form-urlencoded) modules.

It seems that classic asp it's missing Request.Form object at all when using Integrated pipeline mode, throwing out error '80004005' at every usage; Request.QueryString instead it's working correctly.

I would not switch back to Classic Pipeline mode as I will loose the benefits of modify the pages rendered by classic ASP. The use of a Isapi filter here it's a nightmare and I won't go into that direction.

Does anyone knows any workaround to get Request.Form working for classic asp when Integrated Pipeline mode is active -or- any way to modify final rendered page output coming from classic asp when using classic pipeline so I can modify it with .net code before sending it to browser?

Thank you for any help, Squiffy

EDIT: Unfortunately, we never found a solution to this problem. In the meantime, we completely rebuilt the site from scratch using much modern solution (yay!). Thanks everybody for your help!

Dooley

Does using just Request("formElement") works? – Townley

Also, can you post what URL (or at least hostname) looks like? And - does this happen with any browser? – Townley

Hi, Request("formElement") also fails, and honestly all the code it's written that way. – Dooley

The url isn't the issue, as I checked with wireshark and the content it's correctly transmitted to the server in the url encoded form. If I change form tag from post to get it works correctly, but I can't use that way as there are sometimes sensible informations I can't show up in the url. – Dooley

Sometimes it is the issue. Like if there's underscore in host name,IE is having problems submitting forms correctly – Townley

Hi, thank you for the reply, but this is not the case. Hostname it's public name, without any special chars. Urls are clean and plain, eg: /dir/page.asp there is nothing more. Parameters are all made by single char, eg: ?a=123&b=name&... As stated in the question, if I switch back to classic pipeline, it works, but I cannot modify the output coming from asp pages, as the .net isn't involved in the pipeline process. – Dooley

Unfortunately, we never found a solution to this problem. In the meantime, we completely rebuilt the site from scratch using much modern solution (yay!). Thanks everybody for your help! – Dooley

Answer 1

I think it's because you use Request.Form in the http module. According to my experiments Request.Form works in asp in integrated mode unless you access it from module before the asp code is processed. There is a suggestion to use HttpServerUtility.TransferRequest on IIS forums in this case. You can use

  const string dontTransferKey = "DONT_TRANSFER_MODULE";
    if (HttpContext.Current.Request.Headers[dontTransferKey] != null)
        return;

    ...............all your http module logic. use Request.Form...................

    HttpContext.Current.Request.Headers.Add(dontTransferKey, "true");
    HttpContext.Current.Server.TransferRequest(HttpContext.Current.Request.Url.AbsolutePath, true);

There are several drawbacks of this solution: if you use more then one http module you need to be sure that they are idempotent. And this could be very difficult in case of third-party modules.

Anthracnose

Answer 2

Just putting it out there, have you tried "Request.Item()" as well?

Assay

Answer 3

The actual reason there is an error reading Request.Form in Classic ASP with your integrated mode + module, is that Classic ASP can only handle reading/processing the binary POST data once.

This means the second read throws an error no matter what.

The documentation of the BinaryRead method mentions the behavior:

The BinaryRead method is used to read the raw data sent by the client as part of a POST request. This method is used for low-level access to this data, as opposed to, for example, using the Request.Form collection to view form data sent in a POST request. After you have used BinaryRead, referring to any variable in the Request.Form collection causes an error. Conversely, after you have referred to a variable in the Request.Form collection, using BinaryWrite will cause an error.

I have seen it often in practice.

In this case, the .NET httpmodule may be reading the POST data, which then causes the Classic ASP Request.Form to error, or vice versa.

Miracle

Hi Raul, thank you for your reply. I think you got "the cause" of the problem. Unfortunately, as stated a few years ago, we never found a solution and website was completely rebuilt since then. :-) Anyway, for the records, I recently had similar issue once again working on an old intranet website. Once again, mixed classic asp and .net with multiple webapps. I solved with a different approach: I made a c++ NativeModule (note: not clr); probably sit more deep in IIS7's core to influence data it works like a charm. I'd suggest to anyone fallen into similar issue to use a NativeModule – Dooley

Answer 4

Not sure if you are using Glimpse, but if you are, I just spent a day trying to figure out why all of a sudden my Classic ASP Request.Forms were failing. Long story short: I commented out the following line in glimpse configuration under :

  <add type="Glimpse.Core.Policy.AjaxPolicy, Glimpse.Core" />

Adding that back in to the ignored types solved my issue. I can now access Request.Form/Request("field") in Classic ASP. I am using Integrated mode, by the way.

Hopes this saves somebody the time I spent today...

Depolymerize