|
Home > Archive > IIS Server > November 2004 > Compression when browser does not support
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 |
Compression when browser does not support
|
|
| Barrisimo 2004-11-23, 6:07 pm |
| 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
| |
| David Wang [Msft] 2004-11-23, 6:07 pm |
| 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
| |
|
| 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
>
>
| |
| David Wang [Msft] 2004-11-28, 2:47 am |
| <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
>
>
|
|
|
|
|