- Aashish
The POST buffer is a stream in IIS and it's read on demand. AFAIK it's forward only - once read there's no way to go backwards to read values again. So if an ASP.NET module early in the request cycle reads the POST buffer as a full stream another tool like ASP won't see the request stream.
Other ASP.NET componenets will see POST values just fine since those get set very early in the pipeline but if you read the stream (and modify it as you are trying to do) you are touching the raw stream and that's forward only.
+++ Rick ---
Thanks for your prompt response.
Yes, this is accomplished in IIS 6 using wildcard application mapping.
I'm not sure if I follow(/agree with) your explanation about the Request object being cleared out as it is read. I thought that the HttpModule is a part of the Request pipeline and therefore, has access to all events of the Request's life-cycle, even more so in IIS 7 when running in integrated pipeline mode, where the ASP.NET request pipeline is integrated with the Web server's Request pipeline.
Please let me know if I missed something.
- Aashish
Client has a Classic ASP application hosted on IIS 7 running in Integrated Pipeline mode. An ASP.NET based HttpModule registered on the IIS application attempts to prevent cross-site scripting attacks. The classic ASP application works fine (without the cross-site scripting attack filter functionality). But as soon as this HttpModule is added to the IIS 7 application, the Request object clears out after an HttpRequest is POSTed from the classic ASP application.
BTW, this same implementation works fine on IIS 6. The code in the HttpModule is listed below, if it helps.
Uhm, how are you getting this to work on IIS 6? With wildcard mappings?
Both ASP and ASP.NET will reasd the post buffer and clear it as it is read since it's being read directly from the inbound IIS stream. Once read the POST buffer is gone. So if you read in ASP.NET then ASP isn't going to get POST data and vice versa AFAIK.
+++ Rick ---
Any ideas, please? Thanks.