WebResource.axd and blowery HttpCompress

[=?Utf-8?B?TWFyaw==?=]

Hi...

We recently upgraded to the blowery.HttpCom press 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.HttpCom press module, the Application.Res ponse.ContentTy pe 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.Conten tType.

Does this ring any bells with anyone?

thanks
Mark

[Steven Cheng[MSFT]]

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-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/subscripti...t/default.aspx.

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


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




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

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

>
>Hi...
>
>We recently upgraded to the blowery.HttpCom press 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.HttpCo mpress module, the Application.Res ponse.ContentTy pe 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.Conte ntType.
>
>Does this ring any bells with anyone?
>
>thanks
>Mark
>
>

[=?Utf-8?B?TWFyaw==?=]

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.Co ntentType set to null.

But if the Accept-Encoding: header is not there, the .axd handler leaves the
Response.Conten tType 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-WebResourceaxd-and-pa

ges-in-ASPNET.aspx

[Steven Cheng[MSFT]]

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==?= <mmodrall@nospa m.nospam>
>References: <BB44A1E2-FA72-4416-A6F6-1165BAB5E3BF@mi crosoft.com>

<i7yxpIMWIHA.36 0@TK2MSFTNGHUB0 2.phx.gbl>

>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.C ontentType set to null.
>
>But if the Accept-Encoding: header is not there, the .axd handler leaves

the

>Response.Conte ntType alone. What's up with that?
>
>Thanks
>Mark
>
>