WebResource.axd and blowery HttpCompress

[Mark]

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

 

[Steven Cheng[MSFT]]

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-WebResourceaxd-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/default.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.




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

 

[Mark]

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]]

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==?= <[email protected]>
References: <[email protected]>

 

[Mark]

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/ViewFeedback.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/ProjectReleases.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]]

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==?= <[email protected]>
References: <[email protected]>

<[email protected]>

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

 

[Mark]

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]]

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==?= <[email protected]>
Subject: RE: WebResource.axd and blowery HttpCompress
Date: Mon, 28 Jan 2008 06:49:04 -0800