David
Mon May 05 15:41:31 CDT 2008
On May 2, 2:34=A0pm, Mike Kraley <mkra...@community.nospam> wrote:
> See answers below:
>
>
>
>
>
> "David Wang" wrote:
> > On May 1, 5:17 am, Mike Kraley <mkra...@community.nospam> wrote:
> > > I've configured my IIS 6 server to use compression as documented inhtt=
p://weblogs.asp.net/owscott/archive/2004/01/12/57916.aspx. Seems to work
> > > fine under normal http access. But when I access the same server via S=
SL,
> > > everything works fine, but there is no compression. I'm using Fiddler =
to see
> > > if the responses are compressed.
>
> > > Is there some additional configuration step I need to perform to allow=
> > > compression under SSL?
>
> > > --
> > > ...Mike
>
> > 1. When you access the same server via SSL, is the request still
> > requiring compression? i.e. is it the exact same HTTP request as over
> > port 80
>
> Yes, that's correct.
>
> > 2. Is Fiddler showing you raw data and if so, how raw? Because it is
> > obviously decrypting or else you won't know the contents, but does it
> > unwind any other transport/content encodings. For example, is the data
> > still chunk encoded or not? Is the data still compressed or not?
>
> In a different configuraion, where SSL is being done at the load balancer,=
> the decrypted responses as seen in Fiddler show that they are compressed, =
so
> that leads me to believe that the data is not being compressed.
>
> Also the message body length after decryption is the same as when I don't
> use SSL in the software SSL case, further leading me to believe there is n=
o
> compression
>
> > 3. How exactly are you determining that "there is no compression"
>
> In Fiddler, under the Session Inspector on the Transformer tab, when a
> session is compressed, you get a header saying that. Also see above.
>
> Is there a better way to check?
>
> ...Mike
>
>
>
>
>
> > The details matter.
>
> > //David
> >
http://w3-4u.blogspot.com
> >
http://blogs.msdn.com/David.Wang
> > //- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
I expect the Message Body to be the same decoded length whether
compression happened or not -- things like compression, SSL
encryption, and Transfer-Encoding are aspects for transport that the
end consumer at Browser-level should not worry about. Of course, the
value and meaning of all these things depend on the observing tool. I
do not trust end-user tools like IE, Fiddler, or anything else when
counting the bytes or verifying HTTP-level behavior -- unless you can
tell me unequivocably where each measurement is taken at every stage
of the HTTP transport/transformation. And since end-user tools hardly
want to show that level of detail, hence my distrust.
For example, Dynamic Compression from IIS is transferred via Chunked
Encoding. If you counted the encrypted bytes, or even the sum of the
encoded chunks, it is most likely different than the count of non-
compressed or even static-compressed content. However, I expect that
once everything is unwound/decoded, that the resulting message body
*must* be the same length (otherwise the transport was lossy, and
that's bad). Hence, my question focuses on when you say "Message Body
Length", which of the prior "lengths" do you (or Fiddler) really
mean?...
I would use WFetch from IIS Diagnostic Tools and have it send an HTTP
request over SSL to the server and see what comes back. WFetch has the
option to show you the "raw" unencrypted bytes as well as the "raw"
undecoded results prior to decompression and dechunking. In
combination with the raw response headers (also shown by WFetch), it
provides enough concrete evidence to say one thing or another about
any request/response.
http://www.microsoft.com/downloads/details.aspx?familyid=3D9bfa49bc-376b-4a5=
4-95aa-73c9156706e7&displaylang=3Den
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//