|
Home > Archive > IIS Server > January 2004 > Re: IIS Compression basics...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: IIS Compression basics...
|
|
|
| thank for the reply!
"Bernard" <qbernard@hotmail.com.discuss> wrote in message
news:%23YC2fG20DHA.1752@tk2msftngp13.phx.gbl...quote:
> A) No, I think this is per box level.
>
> B) I believe compression only happen during transmission,
> when it reaches client end, it will be decompress and loaded in browser.
>
> C) No idea, but pretty minimum.
>
> D) Read -
>
http://www.microsoft.com/technet/pr...ty/httpcomp.aspquote:
>
>
> --
> Regards,
> Bernard Cheah
> http://support.microsoft.com/
> Please respond to newsgroups only ...
>
>
>
> "Yuval" <yuvals@britannica-ks.com> ????
> news:OjPGtk10DHA.3196@TK2MSFTNGP11.phx.gbl...
server[QUOTE][color=darkred]
>
>
| |
|
| Hi Egbert,
Thanks for the input!
Same IE caching issue,,, I looked at this article
http://www.asptoday.com/content.asp?id=2053....
Please take a look at the "Gotchas" paragraph:
Gotchas
However, compression also has some nasty bugs that can bite you if you are
not careful. I have already touched on the problem with proxy servers - some
proxy servers might cache compressed content and serve it out to client that
does not support compression - rendering that content useless to that
client. To avoid this, by default IIS compression sets the cache control
headers to instruct proxies not to cache the file. For an intranet
application, this will probably not be an issue.
IIS will also set the file expiry to be sometime in 1997 - so that the
client browser will not cache any compressed files. This is explained in
Microsoft knowledge base article 272596 - "IIS: Enabling HTTP Compression
Returns Content with January 1, 1997 Expiration Date"
(http://support.microsoft.com/defaul...b;en-us;Q272596). For
dynamic content, this will not be an issue - as we don't want the browser to
cache it anyway. But for static information - such as reference data and
lookup lists - the browser cache can be used to great advantage. However,
when changing this expiration setting, another nasty bug is exposed - this
time, in Internet Explorer. Internet Explorer will happily cache compressed
files, but for most file types, including HTML, CSS and JavaScript, it will
fail to load them from its cache the next time you visit. Ouch. This pretty
much means that the browser cache is useless for compressed files. And the
browser cache is very important if we want to preserve network bandwidth.
What this ultimately means, is that even if you get 5:1 compression on a
file, request it more than 5 times and it would have been cheaper to get the
uncompressed version, then cache it in the browser cache.
Luckily, due to some quirk of Microsoft fate, caching of compressed XML
files works just fine. So if your application uses XML configuration files,
reference data lists, or other XML files, you can enable compression and
enjoy the benefits.
thanks
Yuval
"Egbert Nierop (MVP for IIS)" <egbert_nierop@nospam.com> wrote in message
news:OFcdkz50DHA.2868@TK2MSFTNGP09.phx.gbl...quote:
> "Yuval" <yuvals@britannica-ks.com> wrote in message
> news:udykoG30DHA.2680@TK2MSFTNGP11.phx.gbl...
> IIS
> directory.
> load
the[QUOTE][color=darkred]
>
> Hi Yuval,
>
> Small misconception. If you want your browser to utilize it's client-side
> cache, you should never delete the origin of the HTML. If you look at the
> IIS log, your browser asks a GET /blah.html and it might (and it does) add
> header (date-last-modified) or it adds another timestamp (Etag) that IIS
> recognizes. IIS might decide to return a HTTP response status 304 which
> means, "I am not modified, you can utilize your cache!"
>
> So, if you delete, the cached file, IIS always would get a return HTTP
> status 200...
>
>
message[QUOTE][color=darkred]
> directory?
> client's
> access'
IIS[QUOTE][color=darkred]
> 6
>
|
|
|
|
|