HTTP Modules

[Tim Payne]

If I were writing an HTTP module where I wanted to access the response text
that was being sent back to the user, what would be the optimum method for
doing this within the module? I'm investigating the viability of using this
for logging some info, and I'm wondering if there are any established or
best practice methods for doing this that will minimise the performance hit
on the server?

Regards,

Tim.

 

[Scott Allen]

Tim:

DinoE has a good article on this topic:

MyTracer Monitors and Traces ASP.NET Apps
http://msdn.microsoft.com/msdnmag/issues/03/04/cuttingedge/

 

[Tim Payne]

Hi Scott,

Thanks for the link, I don't think it's quite what I'm looking for.......
Basically what I need to be able to do is intercept the response text being
sent back to the user after their web request has been processed, to parse
through looking for specific information in the response text, which will
then be logged to a database or log file. I think the way to do this would
be with a HTTP Module (so I can do it on all pages and easily deploy the
solution on several sites), utitlising a HTTP filter so I can access the
final response.text. What I'm interested in knowing is if there is an
optimum way to achieve this, keeping the additional overhead as low as
possible. Basically I'm doing a proof of concept in C# to see how well it
performs and to see if the overhead is acceptable enough to not need to have
to write an ISAPI filter instead.

Regards,

Tim.

 

[Scott Allen]

Hi Tim:

Ah yes, I think I see now. I know I've read an article on the topic but I
can't seem to find it now. I'm sure the code was using an HTTP Module and
hooking the EndRequest event. I know one potential problem with EndRequest
is that it will not fire if you have Response.Redirect or Server.Transfer
in you code the event will be missed. Personally I'd try to keep this in
managed code, ISAPI filters were hard to debug and configure.

 

[John Timney \(ASP.NET MVP\)]

If your doing this via n ihttpmodule then you need to hook into the
response.filter, its gives access to the response text as a binary stream
which you need to convert to a string to work with, and then back again to
binary before forwarding your finalized response out.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

 

[Patrice]

See httpResponse.Filter that allows to define a stream that will receive
what is written to httpResponse...

You could also explain what exactly you try to capture to see if someone
could come up with another approach to perform the same job...

Patrice

 

[Tim Payne]

I've managed to get a working concept up and running using a HTTP Module and
a HTTP Filter, as per the suggestion of several of the poepl who have
replied here. Basically, what the system does is look through the response
text for specific tracking tags and logs them into a database. It doesn't
actually modify the text, so all I'm doing is converting the bits to a text
string, parsing out the tags and logging them if they're present, and then
carrying on with the response as normal (after cleaning up all the
connection objects etc). It seems to woork ok, the only odd issue that I've
noticed is that under stress, using ACT, I get a fairly high number of 401
errors on all of the aspx pages, even though no authentication is being
used, and the same pages ran error free under the same load without the
module in place. Does anyone know what could be causing this to happen? My
initial gues is that it could be some kind of ado.net issue.......

Thanks for all the advice so far guys!

Regards,

Tim.

 

[Patrice]

How are those tracking tags created ? Perhaps could they be recorded at the
source.

For the specific problem, are you using "no authentication" or are you using
"Integrated Window Authentication" on your dev machine ? If the later, try
http://support.microsoft.com/kb/322032/en-us

Patrice

 

[Scott Allen]

No problem - John got the piece I couldn't remember with Response.Filter.

 

[DustinFrenton]

The sheer amount of errors you are recieving are how the stream is being
sent. If you put a breakpoint in your ReleaseRequestState, you will
notice that it stops multiple times. It sends in ~ 32k packets for the
page. So if you page is a larger size it will send multiple times. If
your doing logic on your context, or something that is not available at
that time you will get a Null Reference error. It just wont crash =).

Toss in a check If Context is null before using it. It should stop some
of the errors