HTTP Compression issues with IIS 5

Hello all.

I'm having many issues trying to implement HTTP compression on IIS 5.

Through my reading of other people's issues on the internet I gather IIS 5
isn't great for HTTP compression but IIS 6 is better. Unfortunately I don't
have IIS 6 yet (our computer leasing terms means that we have what we have
for another couple of years)

Background: The company I work for has many branches that are located in
rural areas (Australia wide). Unfortunately our telecommunications systems
are a little behind the rest of the world when it comes to our rural areas
(just above smoke signals) and the bandwidth to the branches is 64k.

The problems I'm having with HTTP compression are:

1. When compression is enabled the Internet Explorer client caches the
dynamic content page (asp) and shows it's cached content when revisiting the
page. If compression is disabled the content is refreshed correctly.

2. Static content sometimes is only partially downloaded. We compress PDF
files as well as other documents and if we try to access some files only a
part is downloaded (Acrobat Reader says the document is damaged). eg 12k of
a 49k document is returned. The 12k is identical to the first 12k of the 49k
file. (this is uncompressed content comparisons)
Upon clearing the cache the file downloads correctly.

3. Binary streaming of content doesn't seem to work properly. We have some
secured documents that we stream via binary to the client and it doesn't
seem to be interpreted correctly by the client.

4. If it's so good why don't Microsoft themselves use it on their site????

If anyone can help or has experienced this could you please let me know?
This has been a very disappointing experience for me and my faith in
Microsoft is at an all time low.

All the best,
Tony

v-wzhang
Tue Sep 21 05:48:03 CDT 2004

Hi Tony,

Please check out the following article. It's generally hitting the
main cause of users experiencing cached content behavior when using
HTTP compression.

319384 Pages Do Not Expire as Expected After Web Site Content Change
http://support.microsoft.com/?id=319384

To prevent dynamic content from being cached, we'd either disable
HTTP Compression on dynamic pages - uncheck the 'Compress application
files' checkbox or modify the HcCacheControlHeader metabase property.

Follow the KB instructed, you can decrease HcCacheControlHeader to a
small value or just set it to "max-age=0" to test. Except for the
ADSUTIL script, using MetaEdit to open your metabase could be a more
clear way to do this:

How To Install MetaEdit 2.2 on Windows NT 4.0 or Windows 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q301386&sd=tec
h

After making the change of this property, you can run iisreset
command to restart IIS services. Some additional points are:

1) In a site properties->HTTP Headers tab, enable Content Expiration
and select 'Expire Immediately'. This will allow IIS set 'no-cache'
in the cache control header of HTTP response and send it to client
browsers.

2) After making all these changes at server-side, a current cached
file may still remain in client Internet Temp folder, means IE may
keep using the local copy and doesn't send a new request to IIS until
24 hours later. Therefore it may be necessary to clear Temporary
Internet files in IE->Internet Options.

For the PDF being truncated behavior and problematic streamed doc,
can you send some sample files to me? I'd like to reproduce the
issues at my side and perform some deeper researching on it. I did
see few cases of PDF file, sometimes the problem is on Adobe Reader's
OLE control(hosted by IE as the actual web client) but not lies on
IIS server. If you simply download the PDF file instead of opening
them in browser(right-click to save as), will the download be
successful? You can send files to my email address directly:
v-wzhang@online.microsoft.com (Please remove online.)

For your last question, to a high volume web site, HTTP compression
costs CPU and response time to save network bandwidth. So in case a
site has enough bandwidth, enable compression doesn't make any sense.
The following White paper contains some useful info to evaluate its
effect:
Web and Application Server Infrastructure - Performance and
Scalability
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technol
ogies/webapp/iis/iis6perf.mspx

Hope some info above can help. Please feel free to let me know if you
meet any problem.
Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

Tony
Tue Sep 21 19:37:19 CDT 2004

Hi WenJun.

My comments are below.

Thank you for replying to my thread.

All the best,
Tony

> Hi Tony,

Hi again.

> Please check out the following article. It's generally hitting the
> main cause of users experiencing cached content behavior when using
> HTTP compression.
>
> 319384 Pages Do Not Expire as Expected After Web Site Content Change
> http://support.microsoft.com/?id=319384
>
> To prevent dynamic content from being cached, we'd either disable
> HTTP Compression on dynamic pages - uncheck the 'Compress application
> files' checkbox or modify the HcCacheControlHeader metabase property.
>
> Follow the KB instructed, you can decrease HcCacheControlHeader to a
> small value or just set it to "max-age=0" to test. Except for the
> ADSUTIL script, using MetaEdit to open your metabase could be a more
> clear way to do this:

I have implemented the "fix" in http://support.microsoft.com/?id=319384 as
you requested and that has fixed the caching problem. I will leave
"max-age=0" as I don't believe that we will want the ASP page's HTML to be
cached client side. One question with this though, does this mean that any
related images that are embeded in the page are not cached as well?
I have installed MetaEdit 2.2 as well and that works very well. I wish I had
known about this before.

> After making the change of this property, you can run iisreset
> command to restart IIS services. Some additional points are:
>
> 1) In a site properties->HTTP Headers tab, enable Content Expiration
> and select 'Expire Immediately'. This will allow IIS set 'no-cache'
> in the cache control header of HTTP response and send it to client
> browsers.

Won't this expire all content on the client immediately including images,
javascript files, etc?
This could defeat the purpose of having compressed content if we have to
resend everything every time.

> 2) After making all these changes at server-side, a current cached
> file may still remain in client Internet Temp folder, means IE may
> keep using the local copy and doesn't send a new request to IIS until
> 24 hours later. Therefore it may be necessary to clear Temporary
> Internet files in IE->Internet Options.

OK.

> For the PDF being truncated behavior and problematic streamed doc,
> can you send some sample files to me? I'd like to reproduce the
> issues at my side and perform some deeper researching on it. I did
> see few cases of PDF file, sometimes the problem is on Adobe Reader's
> OLE control(hosted by IE as the actual web client) but not lies on
> IIS server. If you simply download the PDF file instead of opening
> them in browser(right-click to save as), will the download be
> successful? You can send files to my email address directly:
> v-wzhang@online.microsoft.com (Please remove online.)

OK. I will send the files directly to the above address (minus "online")

> For your last question, to a high volume web site, HTTP compression
> costs CPU and response time to save network bandwidth. So in case a
> site has enough bandwidth, enable compression doesn't make any sense.
> The following White paper contains some useful info to evaluate its
> effect:
> Web and Application Server Infrastructure - Performance and
> Scalability
> http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technol
> ogies/webapp/iis/iis6perf.mspx

True but the true test of a product under real life conditions, especially
your own product, is to use it on your own site. Surely these problems
wouldn't exist if Microsoft used it at least on a sub-section of their site.
Also, the page loads would be considerably faster if it was implemented,
especially on some of Microsoft's large text based areas. How can Microsoft
improve on something and promote it if they don't use it themself?

> Hope some info above can help. Please feel free to let me know if you
> meet any problem.
> Best regards,

Thank you again. Your help in this matter is greatly appreciated.

> WenJun Zhang
> Microsoft Online Support
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> Get Secure! - www.microsoft.com/security
>

v-wzhang
Thu Sep 23 06:02:33 CDT 2004

Hi Tony,

"Won't this expire all content on the client immediately including
images, javascript files, etc? This could defeat the purpose of
having compressed content if we have to resend everything every time."

Sorry I forgot this question. You needn't worry about this. I did
test and see IIS still would send 304(not modified) response to
clients when using HTTP compression. 304 response doesn't have any
actual data, it simply tells client the local cache still can be used
and hasn't been expired. IIS will reply 304 if client attach a last
modified time of its local cache in http request and the time isn't
earlier than the file's on server.

Formerly IIS5 did have a bug on this behavior but it has been fixed
in service pack 3: 307633 IIS Does Not Return an HTTP 304 Not
Modified Message for Compressed
http://support.microsoft.com/?id=307633

I previously suggest you select 'expire immediately' to see if this
can help resolve the ASP caching problem. Since the problem is worked
out by max-age=0, now you can rollback it or use the content
expiration options(in HTTP Headers tab) to control the web client
cache behavior, the setting can be set at each individual file level.

Furthermore, actually css and js are not compressed file types by
default. The default ones are only: html/htm and txt. You can
manually add them to HcFileExtensions by using MetaEdit:

HOW TO: Specify Additional Document Types for HTTP Compression
http://support.microsoft.com/default.aspx?scid=kb;en-us;234497

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

Tony
Fri Sep 24 00:31:02 CDT 2004

This is a multi-part message in MIME format.

------=_NextPart_000_0156_01C4A247.4EDE0F50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi again WehJun.

Thanks for your response.=20

This is a good thing as content that we change infrequently we wouldn't =
want to resend.=20

Since we have SP4 on the W2K box we shouldn't have to worry about the =
"307633 IIS Does Not Return an HTTP 304 Not Modified Message for =
Compressed" issue.

I have added css and js extensions to the static content behorehand =
using the adsutil script.

I gather you haven't had much of a chance to look at the files I sent =
you?=20

I thank you again for taking the time out to look at them.

All the best,

Tony

""WenJun Zhang[msft]"" <v-wzhang@online.microsoft.com> wrote in message =
news:9xsEYzVoEHA.404@cpmsftngxa06.phx.gbl...
> Hi Tony,
>=20
> "Won't this expire all content on the client immediately including=20
> images, javascript files, etc? This could defeat the purpose of=20
> having compressed content if we have to resend everything every time."
>=20
> Sorry I forgot this question. You needn't worry about this. I did=20
> test and see IIS still would send 304(not modified) response to=20
> clients when using HTTP compression. 304 response doesn't have any=20
> actual data, it simply tells client the local cache still can be used=20
> and hasn't been expired. IIS will reply 304 if client attach a last=20
> modified time of its local cache in http request and the time isn't=20
> earlier than the file's on server.
>=20
> Formerly IIS5 did have a bug on this behavior but it has been fixed=20
> in service pack 3: 307633 IIS Does Not Return an HTTP 304 Not=20
> Modified Message for Compressed=20
> http://support.microsoft.com/?id=3D307633
>=20
> I previously suggest you select 'expire immediately' to see if this=20
> can help resolve the ASP caching problem. Since the problem is worked=20
> out by max-age=3D0, now you can rollback it or use the content=20
> expiration options(in HTTP Headers tab) to control the web client=20
> cache behavior, the setting can be set at each individual file level.
>=20
> Furthermore, actually css and js are not compressed file types by=20
> default. The default ones are only: html/htm and txt. You can=20
> manually add them to HcFileExtensions by using MetaEdit:
>=20
> HOW TO: Specify Additional Document Types for HTTP Compression=20
> http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;234497
>=20
> Best regards,
>=20
> WenJun Zhang
> Microsoft Online Support
> This posting is provided "AS IS" with no warranties, and confers no=20
> rights.
> Get Secure! - www.microsoft.com/security
>
------=_NextPart_000_0156_01C4A247.4EDE0F50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>
Hi again WehJun.
Thanks for your response. 
This is a good thing as content that we =
change=20
infrequently we wouldn't want to resend. 
Since we have SP4 on the W2K box we =
shouldn't have to=20
worry about the "307633 IIS Does Not Return an HTTP 304 Not Modified =
Message for=20
Compressed" issue.
I have added css and js extensions to the =
static=20
content behorehand using the adsutil script.
I gather you haven't had much of a chance =
to look at=20
the files I sent you? 
I thank you again for taking the time out =
to look at=20
them.
All the best,
Tony</DIV>
<DIV>""WenJun Zhang[msft]"" <<A=20
href=3D"mailto:v-wzhang@online.microsoft.com">v-wzhang@online.microsoft.com</A>>=20
wrote in message <A=20
href=3D"news:9xsEYzVoEHA.404@cpmsftngxa06.phx.gbl">news:9xsEYzVoEHA.404@cpmsftngxa06.phx.gbl</A>...</DIV>> Hi =
Tony, > >=20
"Won't this expire all content on the client immediately including =
 >=20
images, javascript files, etc? This could defeat the purpose of > =
having=20
compressed content if we have to resend everything every time." > =
 >=20
Sorry I forgot this question. You needn't worry about this. I did =
 > test=20
and see IIS still would send 304(not modified) response to > =
clients when=20
using HTTP compression. 304 response doesn't have any > actual =
data, it=20
simply tells client the local cache still can be used > and =
hasn't been=20
expired. IIS will reply 304 if client attach a last > modified =
time of=20
its local cache in http request and the time isn't > earlier than =
the=20
file's on server. > > Formerly IIS5 did have a bug on this =
behavior=20
but it has been fixed > in service pack 3: 307633 IIS Does Not =
Return an=20
HTTP 304 Not > Modified Message for Compressed > <A =

href=3D"http://support.microsoft.com/?id=3D307633">http://support.microsoft.com/?id=3D307633</A> > > I previously suggest you select 'expire =
immediately' to see=20
if this > can help resolve the ASP caching problem. Since the =
problem is=20
worked > out by max-age=3D0, now you can rollback it or use the =
content=20
 > expiration options(in HTTP Headers tab) to control the web =
client=20
 > cache behavior, the setting can be set at each individual file=20
level. > > Furthermore, actually css and js are not =
compressed file=20
types by > default. The default ones are only: html/htm and txt. =
You can=20
 > manually add them to HcFileExtensions by using =
MetaEdit: >=20
 > HOW TO: Specify Additional Document Types for HTTP Compression =
 >=20
<A=20
href=3D"http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;234497"=
><FONT=20
face=3DArial=20
size=3D2>http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;234497=
</A> <FONT=20
face=3DArial size=3D2>> > Best regards, > > =
WenJun=20
Zhang > Microsoft Online Support > This posting is provided =
"AS IS"=20
with no warranties, and confers no > rights. > Get Secure! =
-=20
<A href=3D"http://www.microsoft.com/security">www.microsoft.com/security</A> >=20
</BODY></HTML>

------=_NextPart_000_0156_01C4A247.4EDE0F50--

v-wzhang
Wed Sep 29 05:44:28 CDT 2004

Hi Tony,

You can use ADODB.Stream which is more convenient. I used your PDF as
the sample file to test the streaming. The problem at my side is
VS.net would be launched by IE to open the file as ASP instead of PDF.

However if I load the page first, then use a form button to send a
new POST request and render the file downloading(using ), it can work
properly. See my attached file in this message.

Most like somehow IE ignores the Content-Type: application/pdf\r\n
specification. However I also tested this will not happen on file
types like .doc or .xls.

I wonder if the 'button click' can be a work around for your issue?
or you may test sending a query string to render the downloading. I
assume as long as the page has been loaded at first, the download
should work fine.

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

v-wzhang
Thu Sep 30 21:42:12 CDT 2004

Hi Tony,

I wonder if you've tested the file I sent to you. Can it succeed in
streaming the .bqy file? Please let me know if the problem persists.
Thanks.

Best regards,

WenJun Zhang
Microsoft Online Support
This posting is provided "AS IS" with no warranties, and confers no
rights.
Get Secure! - www.microsoft.com/security

HTTP Compression issues with IIS 5

RE: HTTP Compression issues with IIS 5 by v-wzhang

Re: HTTP Compression issues with IIS 5 by Tony

Re: HTTP Compression issues with IIS 5 by v-wzhang

Re: HTTP Compression issues with IIS 5 by Tony

Re: HTTP Compression issues with IIS 5 by v-wzhang

Re: HTTP Compression issues with IIS 5 by v-wzhang