Re: Compression when browser does not support
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 11/28/04
- Next message: David Wang [Msft]: "Re: ADSI script for IIS 5.0 can not run in IIS 6.0"
- Previous message: Timothy J. Bruce: "IIS Authentication Providers"
- In reply to: Ian: "Re: Compression when browser does not support"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 28 Nov 2004 01:23:01 -0800
<grin> Thanks for the tip.
Just to note: those are browser-side optimizations that say nothing about
IIS6's support for HTTP compression. :-) Those scenarios work fine using a
dumb HTTP client...
-- //David IIS This posting is provided "AS IS" with no warranties, and confers no rights. // "Ian" <Ixpah@newsgroup.nospam> wrote in message news:%23Dh5HBw0EHA.2156@TK2MSFTNGP10.phx.gbl... Ah, if only it was that easy. :) My personal experience is that unpatched versions of IE, possibly in conjunction with intermediate proxies, can sometimes display garbled pages. Also, if you use ETag to do conditional gets using compression will break this feature when using IE. Also, it's my understanding that IE doesn't handle the Vary header very well, which can also stop conditional gets from working. Ian. "David Wang [Msft]" <someone@online.microsoft.com> wrote in message news:upy$D5a0EHA.2316@TK2MSFTNGP15.phx.gbl... > It works in the optimal manner as expected. > > Compression, like most everything else related to HTTP, is negotiated > between client and server: > - Clients send Accept-Encoding: header to indicate to the server the > ability > to handle additional encodings (including gzip, deflate, etc). > - Server behavior is in the form of allow/disallow compression IF the > client > indicates ability to handle it > > So, it is safe to configure the server to allow compression: > - If the client does not send "Accept-Encoding: gzip", the server will not > send compressed content regardless of configuration > - If the client sent "Accept-Encoding: gzip" but the server disallowed > compression, server will not send compressed content > - If the client sent "Accept-Encoding: gzip" AND the server allows > compression, then server sends compressed content > > Most things on the Web (authentication, authorization, transport/encoding) > are a matter of negotiation. > - Web browsers/servers are NOT clairvoyant to know the right answer before > negotiation (i.e. browser do not know server requires authentication > before > trying anonymous and failing. Nor do they know the right client/server > certificate before negotiation, etc). > - They are also NOT all-powerful to make something work if you > misconfigure > negotiation (such as enforcing gzip compression when client only supports > deflate, etc). > > -- > //David > IIS > This posting is provided "AS IS" with no warranties, and confers no > rights. > // > "Barrisimo" <Barrisimo@discussions.microsoft.com> wrote in message > news:BFEF76AE-9E2F-4322-A69D-AA7D4990930E@microsoft.com... > Hi, > I am seeing conflicting information on this question. > What happens if I have compression enabled if the users browser does not > support compression? > I am running IIS 6.0. > I want to make sure that if I have compression enabled, my pages look OK > even to browsers that do not support compression. > > Thanks, > Barrisimo > >
- Next message: David Wang [Msft]: "Re: ADSI script for IIS 5.0 can not run in IIS 6.0"
- Previous message: Timothy J. Bruce: "IIS Authentication Providers"
- In reply to: Ian: "Re: Compression when browser does not support"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
