WebResource.axd and blowery HttpCompress

Hi...

We recently upgraded to the blowery.HttpCompress module for .Net 2.0 (I
know, long time coming), and I've been investigating some exceptions that
have ended up in our log as a result.

I'm new to some of the modules involved, but the exception I've found is
that when a request comes in for WebResource.axd with an Accept-Encoding:
header of gzip or deflate, when the process gets handed to the
blowery.HttpCompress module, the Application.Response.ContentType is set to
null.

Without the Accept-Encoding: header or with any other value, it actually has
the right ContentType.

Since the HttpCompress method I have the breakpoint on is the entrypoint for
the module, I can't figure out what other process is nulling out the
Response.ContentType.

Does this ring any bells with anyone?

thanks
Mark

RE: WebResource.axd and blowery HttpCompress

Hi Mark,

I think you may have been running into a issue similar to the following one:

ASP.NET 2.0: Http Compression and WebResource.axd
http://blogs.x2line.com/al/archive/2005/12/03/1351.aspx

in which they suggest to exclude the webresource.axd path so as to avoid
the problem.

Also, I found someone else implement their own compression module that can
resolve the problem(by wrapper the webresource.axd returned stream with
their own module):

#HTTP compression of WebResource.axd and pages in ASP.NET
http://blog.madskristensen.dk/post/HTTP-compression-of-WebRe sourceaxd-and-pa
ges-in-ASPNET.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx .

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.




--------------------
>From: =?Utf-8?B?TWFyaw==?=
>Subject: WebResource.axd and blowery HttpCompress
>Date: Wed, 16 Jan 2008 11:47:04 -0800

>
>Hi...
>
>We recently upgraded to the blowery.HttpCompress module for .Net 2.0 (I
>know, long time coming), and I've been investigating some exceptions that
>have ended up in our log as a result.
>
>I'm new to some of the modules involved, but the exception I've found is
>that when a request comes in for WebResource.axd with an Accept-Encoding:
>header of gzip or deflate, when the process gets handed to the
>blowery.HttpCompress module, the Application.Response.ContentType is set
to
>null.
>
>Without the Accept-Encoding: header or with any other value, it actually
has
>the right ContentType.
>
>Since the HttpCompress method I have the breakpoint on is the entrypoint
for
>the module, I can't figure out what other process is nulling out the
>Response.ContentType.
>
>Does this ring any bells with anyone?
>
>thanks
>Mark
>
>

RE: WebResource.axd and blowery HttpCompress

Hi Steven...

Thank you for the links. It does seem as though both of these guys ran into
the same problem. It seems that both work-arounds, however, don't really get
to the root of the issues.

Why is the module handling the .axd requests so incompatible with other
modules? Why doesn't it allow itself to be put in a filter chain?

One odd little quirk I found was that if the browser presents an
Accept-Encoding: gzip header, then the .axd handler somehow gets the
app.Response.ContentType set to null.

But if the Accept-Encoding: header is not there, the .axd handler leaves the
Response.ContentType alone. What's up with that?

Thanks
Mark


"Steven Cheng[MSFT]" wrote:

> ASP.NET 2.0: Http Compression and WebResource.axd
> http://blogs.x2line.com/al/archive/2005/12/03/1351.aspx
>
> in which they suggest to exclude the webresource.axd path so as to avoid
> the problem.
>
> Also, I found someone else implement their own compression module that can
> resolve the problem(by wrapper the webresource.axd returned stream with
> their own module):
>
> #HTTP compression of WebResource.axd and pages in ASP.NET
> http://blog.madskristensen.dk/post/HTTP-compression-of-WebRe sourceaxd-and-pa
> ges-in-ASPNET.aspx

RE: WebResource.axd and blowery HttpCompress

Hi Mark,

Yes, that does sound quite unexpected. I think it may due to some certain
code logic in the resource generator handler that ASP.NET used. There're
some certain component in runtime which may hard code some behavior and
these will cause problem if our application try changing the external code
logic. IMO, if possible, I would still recommend exclude the axd path for
compression if possible.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
>From: =?Utf-8?B?TWFyaw==?=
>References:

>Subject: RE: WebResource.axd and blowery HttpCompress
>Date: Thu, 17 Jan 2008 07:14:00 -0800

>
>Hi Steven...
>
>Thank you for the links. It does seem as though both of these guys ran
into
>the same problem. It seems that both work-arounds, however, don't really
get
>to the root of the issues.
>
>Why is the module handling the .axd requests so incompatible with other
>modules? Why doesn't it allow itself to be put in a filter chain?
>
>One odd little quirk I found was that if the browser presents an
>Accept-Encoding: gzip header, then the .axd handler somehow gets the
>app.Response.ContentType set to null.
>
>But if the Accept-Encoding: header is not there, the .axd handler leaves
the
>Response.ContentType alone. What's up with that?
>
>Thanks
>Mark
>
>

RE: WebResource.axd and blowery HttpCompress

Hi Steven...

I've been Googling around a bit more on this, and it's been hard to find any
specifics, though I've found a number of references to the bug/feature.

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedb ack.aspx?FeedbackID=105150

Microsoft seems to acknowledge the bug, but after a year or so it's closed
"no plans to fix" without comment.

http://www.codeplex.com/httpcompression/Release/ProjectRelea ses.aspx?ReleaseId=7004

is another blowery-like compression module that apparently dug deeper into
the issue and has worked around it (with some disparaging comments about
Microsoft's "feature") but without more detail it's hard to evaluate their
solution.

Both posts seem to imply that the AXD handler sets a flag on the httpwriter
associated with the request to disallow any further i/o on the request
(presumably to protect the integrity of the embedded resource). This has the
odd side-effects, I guess, of nulling out the ContentType member and a few
other things.

The comments on this other compression filter also allude to odd filter
interaction if some code does a Response.End while processing a request.

To both, the code authors say that fix is to find that _ignoreFutureWrites
flag and flip it back.

But the bug filed with MS seems to indicate that flag has some kind of race
condition associated with it, but there are no details there to go on.

Is there anyone you can ask about this bug? Why was it closed "no-fix"?
What's the race condition?

Thanks
Mark


"Steven Cheng[MSFT]" wrote:

> Hi Mark,
>
> Yes, that does sound quite unexpected. I think it may due to some certain
> code logic in the resource generator handler that ASP.NET used. There're
> some certain component in runtime which may hard code some behavior and
> these will cause problem if our application try changing the external code
> logic. IMO, if possible, I would still recommend exclude the axd path for
> compression if possible.
>
> Sincerely,
>
> Steven Cheng
>
> Microsoft MSDN Online Support Lead
>
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> --------------------
> >From: =?Utf-8?B?TWFyaw==?=
> >References:
>
> >Subject: RE: WebResource.axd and blowery HttpCompress
> >Date: Thu, 17 Jan 2008 07:14:00 -0800
>
> >
> >Hi Steven...
> >
> >Thank you for the links. It does seem as though both of these guys ran
> into
> >the same problem. It seems that both work-arounds, however, don't really
> get
> >to the root of the issues.
> >
> >Why is the module handling the .axd requests so incompatible with other
> >modules? Why doesn't it allow itself to be put in a filter chain?
> >
> >One odd little quirk I found was that if the browser presents an
> >Accept-Encoding: gzip header, then the .axd handler somehow gets the
> >app.Response.ContentType set to null.
> >
> >But if the Accept-Encoding: header is not there, the .axd handler leaves
> the
> >Response.ContentType alone. What's up with that?
> >
> >Thanks
> >Mark
> >
> >
>
>

RE: WebResource.axd and blowery HttpCompress

Thanks for your reply Mark,

Yes, there does exist some bug report that will not be fixed currently.
That may due to some priority or schedule related reasons. Or sometimes it
may due to the certain feature is still not used quite often. So far the
feedback site would be the most appropriate place for us to submit the
request. You can also vote on the bug or submit a new one.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

>From: =?Utf-8?B?TWFyaw==?=
>References:



>Subject: RE: WebResource.axd and blowery HttpCompress
>Date: Mon, 21 Jan 2008 07:53:01 -0800

>
>Hi Steven...
>
>I've been Googling around a bit more on this, and it's been hard to find
any
>specifics, though I've found a number of references to the bug/feature.
>
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedb ack.aspx?Feedbac
kID=105150
>
>Microsoft seems to acknowledge the bug, but after a year or so it's closed
>"no plans to fix" without comment.
>
http://www.codeplex.com/httpcompression/Release/ProjectRelea ses.aspx?Release
Id=7004
>
>is another blowery-like compression module that apparently dug deeper into
>the issue and has worked around it (with some disparaging comments about
>Microsoft's "feature") but without more detail it's hard to evaluate their
>solution.
>
>Both posts seem to imply that the AXD handler sets a flag on the
httpwriter
>associated with the request to disallow any further i/o on the request
>(presumably to protect the integrity of the embedded resource). This has
the
>odd side-effects, I guess, of nulling out the ContentType member and a few
>other things.
>
>The comments on this other compression filter also allude to odd filter
>interaction if some code does a Response.End while processing a request.
>
>To both, the code authors say that fix is to find that _ignoreFutureWrites
>flag and flip it back.
>
>But the bug filed with MS seems to indicate that flag has some kind of
race
>condition associated with it, but there are no details there to go on.
>
>Is there anyone you can ask about this bug? Why was it closed "no-fix"?
>What's the race condition?
>
>Thanks
>Mark
>
>
>"Steven Cheng[MSFT]" wrote:
>
>> Hi Mark,
>>
>> Yes, that does sound quite unexpected. I think it may due to some
certain
>> code logic in the resource generator handler that ASP.NET used. There're
>> some certain component in runtime which may hard code some behavior and
>> these will cause problem if our application try changing the external
code
>> logic. IMO, if possible, I would still recommend exclude the axd path
for
>> compression if possible.
>>
>> Sincerely,
>>
>> Steven Cheng
>>
>> Microsoft MSDN Online Support Lead
>>
>>
>> This posting is provided "AS IS" with no warranties, and confers no
rights.
>>
>> --------------------
>> >From: =?Utf-8?B?TWFyaw==?=
>> >References:
>>
>> >Subject: RE: WebResource.axd and blowery HttpCompress
>> >Date: Thu, 17 Jan 2008 07:14:00 -0800
>>
>> >
>> >Hi Steven...
>> >
>> >Thank you for the links. It does seem as though both of these guys ran
>> into
>> >the same problem. It seems that both work-arounds, however, don't
really
>> get
>> >to the root of the issues.
>> >
>> >Why is the module handling the .axd requests so incompatible with other
>> >modules? Why doesn't it allow itself to be put in a filter chain?
>> >
>> >One odd little quirk I found was that if the browser presents an
>> >Accept-Encoding: gzip header, then the .axd handler somehow gets the
>> >app.Response.ContentType set to null.
>> >
>> >But if the Accept-Encoding: header is not there, the .axd handler
leaves
>> the
>> >Response.ContentType alone. What's up with that?
>> >
>> >Thanks
>> >Mark
>> >
>> >
>>
>>
>

RE: WebResource.axd and blowery HttpCompress

Hi Steven...

I'm less concerned that Microsoft doesn't plan to fix the bug than I am with
the lack of information to work around it.

The work-around you pointed me to was really kludgy and of questionable
performance (hooking the module upstream and then doing a loop-back call to
service the request).

The other work-around I found by googling around seems much more efficient
(flipping the _ignoreFutureWrites flag back to false on the response
HtmlWriter) but since Microsoft hints that the .axd handler sets it to avoid
some kind of race condition, that seems a bit dicey to fiddle with.

I'm looking for the detail to make a better decision.

Are you saying the best way to get this information is to re-open the bug or
submit a new one?

Thanks
Mark


"Steven Cheng[MSFT]" wrote:

> Thanks for your reply Mark,
>
> Yes, there does exist some bug report that will not be fixed currently.
> That may due to some priority or schedule related reasons. Or sometimes it
> may due to the certain feature is still not used quite often. So far the
> feedback site would be the most appropriate place for us to submit the
> request. You can also vote on the bug or submit a new one.
>
> Sincerely,
>
> Steven Cheng
>
> Microsoft MSDN Online Support Lead
>
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> --------------------
>
> >From: =?Utf-8?B?TWFyaw==?=
> >References:
>
>
>
> >Subject: RE: WebResource.axd and blowery HttpCompress
> >Date: Mon, 21 Jan 2008 07:53:01 -0800
>
> >
> >Hi Steven...
> >
> >I've been Googling around a bit more on this, and it's been hard to find
> any
> >specifics, though I've found a number of references to the bug/feature.
> >
> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedb ack.aspx?Feedbac
> kID=105150
> >
> >Microsoft seems to acknowledge the bug, but after a year or so it's closed
> >"no plans to fix" without comment.
> >
> http://www.codeplex.com/httpcompression/Release/ProjectRelea ses.aspx?Release
> Id=7004
> >
> >is another blowery-like compression module that apparently dug deeper into
> >the issue and has worked around it (with some disparaging comments about
> >Microsoft's "feature") but without more detail it's hard to evaluate their
> >solution.
> >
> >Both posts seem to imply that the AXD handler sets a flag on the
> httpwriter
> >associated with the request to disallow any further i/o on the request
> >(presumably to protect the integrity of the embedded resource). This has
> the
> >odd side-effects, I guess, of nulling out the ContentType member and a few
> >other things.
> >
> >The comments on this other compression filter also allude to odd filter
> >interaction if some code does a Response.End while processing a request.
> >
> >To both, the code authors say that fix is to find that _ignoreFutureWrites
> >flag and flip it back.
> >
> >But the bug filed with MS seems to indicate that flag has some kind of
> race
> >condition associated with it, but there are no details there to go on.
> >
> >Is there anyone you can ask about this bug? Why was it closed "no-fix"?
> >What's the race condition?
> >
> >Thanks
> >Mark
> >
> >
> >"Steven Cheng[MSFT]" wrote:
> >
> >> Hi Mark,
> >>
> >> Yes, that does sound quite unexpected. I think it may due to some
> certain
> >> code logic in the resource generator handler that ASP.NET used. There're
> >> some certain component in runtime which may hard code some behavior and
> >> these will cause problem if our application try changing the external
> code
> >> logic. IMO, if possible, I would still recommend exclude the axd path
> for
> >> compression if possible.
> >>
> >> Sincerely,
> >>
> >> Steven Cheng
> >>
> >> Microsoft MSDN Online Support Lead
> >>
> >>
> >> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> >>
> >> --------------------
> >> >From: =?Utf-8?B?TWFyaw==?=
> >> >References:
> >>
> >> >Subject: RE: WebResource.axd and blowery HttpCompress
> >> >Date: Thu, 17 Jan 2008 07:14:00 -0800
> >>
> >> >
> >> >Hi Steven...
> >> >
> >> >Thank you for the links. It does seem as though both of these guys ran
> >> into
> >> >the same problem. It seems that both work-arounds, however, don't
> really
> >> get
> >> >to the root of the issues.
> >> >
> >> >Why is the module handling the .axd requests so incompatible with other
> >> >modules? Why doesn't it allow itself to be put in a filter chain?
> >> >
> >> >One odd little quirk I found was that if the browser presents an
> >> >Accept-Encoding: gzip header, then the .axd handler somehow gets the
> >> >app.Response.ContentType set to null.
> >> >
> >> >But if the Accept-Encoding: header is not there, the .axd handler
> leaves
> >> the
> >> >Response.ContentType alone. What's up with that?
> >> >
> >> >Thanks
> >> >Mark
> >> >
> >> >
> >>
> >>
> >
>
>

RE: WebResource.axd and blowery HttpCompress

Thanks for your reply Mark,

If what you need is an rapid fix(or hotfix) that can help you work around
the issue, I suggest you directly contact the product support team to
continue work on this issue. Since further troubleshooting or potential
workaround may require some cowork with the product team engineer and
that will be quite restricted to newsgroup support.

Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx .

Thanks for your understanding.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------
>Thread-Topic: WebResource.axd and blowery HttpCompress
>thread-index: AchhvO1QDEH07biHRoeuHYTwhwq31A==
>X-WBNR-Posting-Host: 72.93.78.3
>From: =?Utf-8?B?TWFyaw==?=
>Subject: RE: WebResource.axd and blowery HttpCompress
>Date: Mon, 28 Jan 2008 06:49:04 -0800

>
>Hi Steven...
>
>I'm less concerned that Microsoft doesn't plan to fix the bug than I am
with
>the lack of information to work around it.
>
>The work-around you pointed me to was really kludgy and of questionable
>performance (hooking the module upstream and then doing a loop-back call
to
>service the request).
>
>The other work-around I found by googling around seems much more efficient
>(flipping the _ignoreFutureWrites flag back to false on the response
>HtmlWriter) but since Microsoft hints that the .axd handler sets it to
avoid
>some kind of race condition, that seems a bit dicey to fiddle with.
>
>I'm looking for the detail to make a better decision.
>
>Are you saying the best way to get this information is to re-open the bug
or
>submit a new one?
>
>Thanks
>Mark
>
>
>"Steven Cheng[MSFT]" wrote:
>
>> Thanks for your reply Mark,
>>
>> Yes, there does exist some bug report that will not be fixed currently.
>> That may due to some priority or schedule related reasons. Or sometimes
it
>> may due to the certain feature is still not used quite often. So far the
>> feedback site would be the most appropriate place for us to submit the
>> request. You can also vote on the bug or submit a new one.
>>
>> Sincerely,
>>
>> Steven Cheng
>>
>> Microsoft MSDN Online Support Lead
>>
>>
>> This posting is provided "AS IS" with no warranties, and confers no
rights.
>>
>> --------------------
>>
>> >From: =?Utf-8?B?TWFyaw==?=
>> >References:
>>
>>
>>
>> >Subject: RE: WebResource.axd and blowery HttpCompress
>> >Date: Mon, 21 Jan 2008 07:53:01 -0800
>>
>> >
>> >Hi Steven...
>> >
>> >I've been Googling around a bit more on this, and it's been hard to
find
>> any
>> >specifics, though I've found a number of references to the bug/feature.
>> >
>>
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedb ack.aspx?Feedbac
>> kID=105150
>> >
>> >Microsoft seems to acknowledge the bug, but after a year or so it's
closed
>> >"no plans to fix" without comment.
>> >
>>
http://www.codeplex.com/httpcompression/Release/ProjectRelea ses.aspx?Release
>> Id=7004
>> >
>> >is another blowery-like compression module that apparently dug deeper
into
>> >the issue and has worked around it (with some disparaging comments
about
>> >Microsoft's "feature") but without more detail it's hard to evaluate
their
>> >solution.
>> >
>> >Both posts seem to imply that the AXD handler sets a flag on the
>> httpwriter
>> >associated with the request to disallow any further i/o on the request
>> >(presumably to protect the integrity of the embedded resource). This
has
>> the
>> >odd side-effects, I guess, of nulling out the ContentType member and a
few
>> >other things.
>> >
>> >The comments on this other compression filter also allude to odd filter
>> >interaction if some code does a Response.End while processing a request.
>> >
>> >To both, the code authors say that fix is to find that
_ignoreFutureWrites
>> >flag and flip it back.
>> >
>> >But the bug filed with MS seems to indicate that flag has some kind of
>> race
>> >condition associated with it, but there are no details there to go on.
>> >
>> >Is there anyone you can ask about this bug? Why was it closed
"no-fix"?
>> >What's the race condition?
>> >
>> >Thanks
>> >Mark
>> >
>> >
>> >"Steven Cheng[MSFT]" wrote:
>> >
>> >> Hi Mark,
>> >>
>> >> Yes, that does sound quite unexpected. I think it may due to some
>> certain
>> >> code logic in the resource generator handler that ASP.NET used.
There're
>> >> some certain component in runtime which may hard code some behavior
and
>> >> these will cause problem if our application try changing the external
>> code
>> >> logic. IMO, if possible, I would still recommend exclude the axd
path
>> for
>> >> compression if possible.
>> >>
>> >> Sincerely,
>> >>
>> >> Steven Cheng
>> >>
>> >> Microsoft MSDN Online Support Lead
>> >>
>> >>
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> >>
>> >> --------------------
>> >> >From: =?Utf-8?B?TWFyaw==?=
>> >> >References:
>> >>
>> >> >Subject: RE: WebResource.axd and blowery HttpCompress
>> >> >Date: Thu, 17 Jan 2008 07:14:00 -0800
>> >>
>> >> >
>> >> >Hi Steven...
>> >> >
>> >> >Thank you for the links. It does seem as though both of these guys
ran
>> >> into
>> >> >the same problem. It seems that both work-arounds, however, don't
>> really
>> >> get
>> >> >to the root of the issues.
>> >> >
>> >> >Why is the module handling the .axd requests so incompatible with
other
>> >> >modules? Why doesn't it allow itself to be put in a filter chain?
>> >> >
>> >> >One odd little quirk I found was that if the browser presents an
>> >> >Accept-Encoding: gzip header, then the .axd handler somehow gets the
>> >> >app.Response.ContentType set to null.
>> >> >
>> >> >But if the Accept-Encoding: header is not there, the .axd handler
>> leaves
>> >> the
>> >> >Response.ContentType alone. What's up with that?
>> >> >
>> >> >Thanks
>> >> >Mark
>> >> >
>> >> >
>> >>
>> >>
>> >
>>
>>
>