Hello everyone,

I have a small problem with IIS6 configuration.

I'm trying to optimize our IIS6 web portal. I activated HTTP compression
both for static and dynamic content, and this works OK when the browser asks
for content directly to the IIS server ...

BUT, when the browser asks for content thru a web proxy (Squid in my case)
dynamic content is effectively served by IIS but as the Content-Length
header is missing, so nor IE or FireFox can handle it !

So my question is : Is there a way to automatically compute and add the
Content-Length header when requesting for dynamic compressed content ?

Any help would be much appreciated.

Best regards,

Eric.

Re: IIS6 + Dynamic Compression => no Content-Length header by David

David
Thu Mar 13 23:54:20 CDT 2008

On Mar 13, 1:36=A0pm, "Eric LAMIDIAUX" <sam.arch...@nospam.org> wrote:
> Hello everyone,
>
> I have a small problem with IIS6 configuration.
>
> I'm trying to optimize our IIS6 web portal. I activated HTTP compression
> both for static and dynamic content, and this works OK when the browser as=
ks
> for content directly to the IIS server ...
>
> BUT, when the browser asks for content thru a web proxy (Squid in my case)=

> dynamic content is effectively served by IIS but as the Content-Length
> header is missing, so nor IE or FireFox can handle it !
>
> So my question is : Is there a way to automatically compute and add the
> Content-Length header when requesting for dynamic compressed content ?
>
> Any help would be much appreciated.
>
> Best regards,
>
> Eric.


This is not a problem with IIS6. This looks to be a bug in your web
proxy.

Static content is... static, so IIS can pre-compress and calculate
effective Content-Length and send it.

Dynamic content is... not static, so IIS cannot calculate effective
Content-Length without buffering the entire response -- and I am sure
that you want IIS to send that 2GB of dynamically generated file
download in 32K chunks at a time instead of buffering 2GB in RAM on
the server just because you want to calculate the Content-Length.
Thus, Dynamic Compression uses Chunked ENcoding to send the compressed
chunks as soon as the application dynamically outputs it.

Both methods are perfectly valid and IE/Firefox handle static or
dynamic compressed content just fine.

Thus, I believe you are talking about some bug in your web proxy.
Squid is known to have atrocious bugs like this.

If you want to optimize your web portal, then start by optimizing your
web proxy and get a real, working one.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Re: IIS6 + Dynamic Compression => no Content-Length header by Eric

Eric
Sun Mar 16 16:47:44 CDT 2008

Hi David,

Thanks for your answer ...

I'll have to discuss that with our network admin ... but I can already guess
what his response will be !

Regards,

Eric.


Re: IIS6 + Dynamic Compression => no Content-Length header by Lognoul,

Lognoul,
Mon Mar 17 04:34:40 CDT 2008

It will not help a lot, but several squid admins at customers already
reported me that they intentionally configured SQUID not to transmit all
headers. For "security" reasons they claimed (as seen on some *NIX forums).
So it may not be a flaw but a (flawed) configuration.

Marc


"Eric LAMIDIAUX" <sam.archepa@nospam.org> wrote in message
news:C0C940A0-4984-426E-9AC7-A17A2583EEAB@microsoft.com...
> Hi David,
>
> Thanks for your answer ...
>
> I'll have to discuss that with our network admin ... but I can already
> guess what his response will be !
>
> Regards,
>
> Eric.
>

Re: IIS6 + Dynamic Compression => no Content-Length header by David

David
Tue Mar 18 00:26:30 CDT 2008

On Mar 17, 2:34=A0am, "Lognoul, Marc \(Private\)" <logno...@hotmail.com>
wrote:
> It will not help a lot, but several squid admins at customers already
> reported me that they intentionally configured SQUID not to transmit all
> headers. For "security" reasons they claimed (as seen on some *NIX forums)=
.
> So it may not be a flaw but a (flawed) configuration.
>
> Marc
>
> "Eric LAMIDIAUX" <sam.arch...@nospam.org> wrote in message
>
> news:C0C940A0-4984-426E-9AC7-A17A2583EEAB@microsoft.com...
>
>
>
> > Hi David,
>
> > Thanks for your answer ...
>
> > I'll have to discuss that with our network admin ... but I can already
> > guess what his response will be !
>
> > Regards,
>
> > Eric.- Hide quoted text -
>
> - Show quoted text -



Well, if SQUID is configured to remove Transfer-Encoding: chunked
response headers, that basically corrupts the HTTP data stream and is
simply broken configuration.

And if SQUID cannot properly handle Transfer-Encoding: chunked
responses (I have seen SQUID bugs in this area in the past), that is a
bug in SQUID.

In either case, the only thing you can control is to not turn on
Dynamic Compression because downstream servers cannot handle it. There
is no such thing as turning on Dynamic Compression and expecting
Content-Length for all the reasons I stated earlier. Given dynamic
data stream, I believe people expect streaming data and not buffered
data behavior.

Of course, one can argue that maybe there should be a choice here for
configuration of buffering or not. Certainly in IIS7 response
buffering is enabled for "reasonably sized" responses by default such
that all content can automagically take advantage of the HTTP.SYS
kernel response cache. But that's not in IIS6 and was introduced in
IIS7 purely because we needed feature parity between ASP.Net request
processing pipeline and IIS6's request processing pipeline to simply
extensibility of IIS7 Integrated Pipeline with managed code (a major
architectural win). So, you get response buffering natively in IIS7 as
a side-effect. :-)


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Re: IIS6 + Dynamic Compression => no Content-Length header by Eric

Eric
Tue Mar 18 11:58:20 CDT 2008

Hi all and thank you for your answers,

I did some testing this afternoon using Squid 2.6 STABLE 18 and IIS6 dynamic
pages compression works thru this release of Squid ... So now it's up to our
Network Admin to upgrade (if he wants to) ...

Concerning Windows Server 2008, I didn't have enougth time to install the
ASP.Net application on IIS7 by now. But I probably will do the test as soon
as I have time ...

Best regards,

Eric.