Re: [AOLSERVER] ns_adp_compress usage - again

2005-02-28 Thread Dossy Shiobara
On 2005.02.28, Eric Lee [EMAIL PROTECTED] wrote:
 BrowserACCEPT_ENCODING  off/Disp:len  on/Disp:len
 IE 5.5 gzip, deflateyes:247   no:210
...
 The way I read this is that:
 IE 5.5 says it can handle gzip, but cannot display it, displays empty page.

This smells like this MSIE bug:

Internet Explorer May Lose the First 2,048 Bytes of Data That Are
Sent Back from a Web Server That Uses HTTP Compression
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3BQ312496

This is exactly why I hate server-side transparent HTTP compression
nonsense.  In 2-3 years, when all these little stupid bugs are finally
fixed in all popular browsers, it might be the right time to do the
compression thing.  But then, maybe narrowband users will only be 5% of
the audience, and compression won't matter anymore, either.

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] ns_adp_compress usage - again

2005-02-28 Thread Michael Matthews
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dossy Shiobara wrote:
| This is exactly why I hate server-side transparent HTTP compression
| nonsense.  In 2-3 years, when all these little stupid bugs are finally
| fixed in all popular browsers, it might be the right time to do the
| compression thing.  But then, maybe narrowband users will only be 5% of
| the audience, and compression won't matter anymore, either.
While I agree with your point, I have to say that compression (or, at
least, the concept of efficiency) will always matter.  Network
bandwidth, even when it becomes obscenely fast right to the home, is
something that should always be considered.  Once you take it for
granted, you'll find ways to overwhelm it.  It still has to flow through
the network(s) the servers reside on, for example, and there's a cost
associated with those pipes that's typically hidden to developers.
| -- Dossy
Mike
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCI0+RXXdpNt6Ev7QRAuxSAKCcuZa6j4howMEFWS2cZFOwl5+ywACgnW0q
6PDgXd5xczfy2qIHN1rMURA=
=e+Az
-END PGP SIGNATURE-
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] ns_adp_compress usage - again

2005-02-28 Thread Eric Lee
OK, that may explain IE 5.5, which is admittedly kind of an antique. What
about IE 6.0 - not broken but is it in fact incapable of handling
compressed input?

From my post:
Browser  ACCEPT_ENCODING  off/Disp:len  on/Disp:len
IE 5.5  gzip, deflate   yes:247   no:210
IE 6.0  deflate   yes:247   yes:247
...
The way I read this is that:
IE 5.5 says it can handle gzip, but cannot display it, displays empty page.
IE 6.0 says it cannot handle gzip and ns_adp_compress does not compress.
...

Apache docs on it's approach to compression at
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html
seem to say they do additional vetting of browsers before deciding to send
something compressed.

A good deal of the pressure on me to do this is coming from my ISP whose
lines are getting overloaded. As I understand it, this affects everyone who
comes to my server, not just narrowband users. Perhaps I've just outgrown
this ISP?

Eric

At 11:41 AM 2/28/05 -0500, you wrote:
On 2005.02.28, Eric Lee [EMAIL PROTECTED] wrote:
 BrowserACCEPT_ENCODING  off/Disp:len  on/Disp:len
 IE 5.5 gzip, deflateyes:247   no:210
...
 The way I read this is that:
 IE 5.5 says it can handle gzip, but cannot display it, displays empty page.

This smells like this MSIE bug:

Internet Explorer May Lose the First 2,048 Bytes of Data That Are
Sent Back from a Web Server That Uses HTTP Compression
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3BQ312496

This is exactly why I hate server-side transparent HTTP compression
nonsense.  In 2-3 years, when all these little stupid bugs are finally
fixed in all popular browsers, it might be the right time to do the
compression thing.  But then, maybe narrowband users will only be 5% of
the audience, and compression won't matter anymore, either.

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] ns_adp_compress usage - again

2005-02-28 Thread Dossy Shiobara
On 2005.02.28, Michael Matthews [EMAIL PROTECTED] wrote:
 While I agree with your point, I have to say that compression (or, at
 least, the concept of efficiency) will always matter.  Network
 bandwidth, even when it becomes obscenely fast right to the home, is
 something that should always be considered.  Once you take it for
 granted, you'll find ways to overwhelm it.  It still has to flow through
 the network(s) the servers reside on, for example, and there's a cost
 associated with those pipes that's typically hidden to developers.

Server-side compression is perfume to cover up the stink of a poor
content representation format (HTML/XML).  Of course, considering how
well-established this poor format has become, solving the real problem
correctly will likely never happen.

Suggesting that compression is the right solution makes me wonder why
people aren't pressuring manufacturers of network-edge hardware (i.e.,
Cisco) to design and implement transparent inter-router compression
standards to minimize the required bandwidth between peers.  It's a
silly suggestion, and IMHO, just as silly as the application-level
compression thing.

The pressure should be applied to content producers to ensure that their
images are optimized and cropped, that the HTML is clean and as much of
it is client-side cacheable, etc.  Browsers and servers should support
things like If-Match: and If-Modified-Since: the ultimate compression is
to not transmit the data more than once, reducing payload to zero bytes.

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] ns_adp_compress usage - again

2005-02-28 Thread Dossy Shiobara
On 2005.02.28, Eric Lee [EMAIL PROTECTED] wrote:
 OK, that may explain IE 5.5, which is admittedly kind of an antique.
 What about IE 6.0 - not broken but is it in fact incapable of handling
 compressed input?

 From my post:
 Browser  ACCEPT_ENCODING  off/Disp:len  on/Disp:len
 IE 5.5  gzip, deflate   yes:247   no:210
 IE 6.0  deflate   yes:247   yes:247

Can you sniff the network and see if IE 6.0 is sending the
Accept-Encoding: header as part of its HTTP request?

 Apache docs on it's approach to compression at
 http://httpd.apache.org/docs-2.0/mod/mod_deflate.html seem to say they
 do additional vetting of browsers before deciding to send something
 compressed.

Yeah, in the end, our compression support will need to jump through an
equal amount of hoops to do this right: that's per-request overhead if
the client claims (accurately or not) that they support compression.
For Apache, it's probably no big deal since it's just a few more
milliseconds of latency per request on top of an already slow
(relatively speaking) model ... but for AOLserver, the impact could be
measurable.  Then again, maybe not: I haven't really tried to measure it
scientifically.

 A good deal of the pressure on me to do this is coming from my ISP
 whose lines are getting overloaded. As I understand it, this affects
 everyone who comes to my server, not just narrowband users.  Perhaps
 I've just outgrown this ISP?

From the sounds of it, I'd say so.

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] ns_adp_compress usage - again

2005-02-28 Thread Bernd Eidenschink
 Apache docs on it's approach to compression at
 http://httpd.apache.org/docs-2.0/mod/mod_deflate.html
 seem to say they do additional vetting of browsers before deciding to send
 something compressed.

hm, the rl_returnz module for AOLserver checks against IE5.5 and adds about
2000 extra whitespace chars on top of the content:

  /* IE 5 has an inexcusably buggy implementation
 on a refresh, it will (sometimes) discard about 2K of text! */

did you ever try rl_returnz to compare the results against ns_adp_compress?


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] ns_adp_compress usage - again

2005-02-28 Thread Eric Lee
Not sure I know what sniff the network implies, but the ACCEPT_ENCODING
column in that table (deflate, but not gzip, for IE 6.0) is the
HTTP_ACCEPT_ENCODING environment variable.

If that's not what you're asking I'll try to find it if you can describe
how to look.

At 12:49 PM 2/28/05 -0500, you wrote:
On 2005.02.28, Eric Lee [EMAIL PROTECTED] wrote:
 OK, that may explain IE 5.5, which is admittedly kind of an antique.
 What about IE 6.0 - not broken but is it in fact incapable of handling
 compressed input?

 From my post:
 Browser  ACCEPT_ENCODING  off/Disp:len  on/Disp:len
 IE 5.5  gzip, deflate   yes:247   no:210
 IE 6.0  deflate   yes:247   yes:247

Can you sniff the network and see if IE 6.0 is sending the
Accept-Encoding: header as part of its HTTP request?

...


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] ns_adp_compress usage - again

2005-02-28 Thread Dossy Shiobara
On 2005.02.28, Eric Lee [EMAIL PROTECTED] wrote:
 Not sure I know what sniff the network implies, but the ACCEPT_ENCODING
 column in that table (deflate, but not gzip, for IE 6.0) is the
 HTTP_ACCEPT_ENCODING environment variable.

I was suggesting using a TCP sniffer like tcpdump or Ethereal.

 If that's not what you're asking I'll try to find it if you can describe
 how to look.

No, that's what I was suggesting although what webserver are you using
to test with?  AOLserver doesn't set environment variables in response
to HTTP requests normally, does it?  Are you using Apache here to do
your tests?

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] ns_adp_compress usage - again

2005-02-28 Thread Eric Lee
I'm using a Perl CGI script under AOLserver 4.0.1 for this.
HTTP_ACCEPT_ENCODING is different for different browsers - well it was the
same for IE5.5, Foxfire and Netscape, but different for IE6.0, so I assumed
it was meaningful.

Eric

At 02:57 PM 2/28/05 -0500, you wrote:
On 2005.02.28, Eric Lee [EMAIL PROTECTED] wrote:
 Not sure I know what sniff the network implies, but the ACCEPT_ENCODING
 column in that table (deflate, but not gzip, for IE 6.0) is the
 HTTP_ACCEPT_ENCODING environment variable.

I was suggesting using a TCP sniffer like tcpdump or Ethereal.

 If that's not what you're asking I'll try to find it if you can describe
 how to look.

No, that's what I was suggesting although what webserver are you using
to test with?  AOLserver doesn't set environment variables in response
to HTTP requests normally, does it?  Are you using Apache here to do
your tests?

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] ns_adp_compress usage - again

2005-02-28 Thread Dossy Shiobara
On 2005.02.28, Eric Lee [EMAIL PROTECTED] wrote:
 I'm using a Perl CGI script under AOLserver 4.0.1 for this.
 HTTP_ACCEPT_ENCODING is different for different browsers - well it was
 the same for IE5.5, Foxfire and Netscape, but different for IE6.0, so
 I assumed it was meaningful.

Wait, what WAS the Accept-Encoding: header from IE 6.0?  What exactly
are we trying to determine, again?

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] ns_adp_compress usage - again

2005-02-28 Thread Eric Lee
From my post this morning, which I was not able to render as a table:

Browser  ACCEPT_ENCODING  off/Disp:len  on/Disp:len
IE 5.5  gzip, deflate  yes:247 no:210
IE 6.0  deflate  yes:247  yes:247

If this means IE6.0 does not accept gzip, is there something else
(deflate) it does accept?

Eric
(I don't know why my previous reply came out empty)

At 04:03 PM 2/28/05 -0500, you wrote:
On 2005.02.28, Eric Lee [EMAIL PROTECTED] wrote:
 I'm using a Perl CGI script under AOLserver 4.0.1 for this.
 HTTP_ACCEPT_ENCODING is different for different browsers - well it was
 the same for IE5.5, Foxfire and Netscape, but different for IE6.0, so
 I assumed it was meaningful.

Wait, what WAS the Accept-Encoding: header from IE 6.0?  What exactly
are we trying to determine, again?

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.


Re: [AOLSERVER] ns_adp_compress usage - again

2005-02-28 Thread Dossy Shiobara
On 2005.02.28, Eric Lee [EMAIL PROTECTED] wrote:
 From my post this morning, which I was not able to render as a table:

 Browser  ACCEPT_ENCODING  off/Disp:len  on/Disp:len
 IE 5.5  gzip, deflate  yes:247 no:210
 IE 6.0  deflate  yes:247  yes:247

 If this means IE6.0 does not accept gzip, is there something else
 (deflate) it does accept?

Yes, from what you observed it appears your IE 6.0 only supports the
deflate encoding and not the gzip encoding.  AOLserver 4.0.10
currently only supports gzip but it's not very hard to add deflate
encoding support.

Rather than continue to muddle with the 4.0.x tree, I'd like to get
everyone to start playing with and testing the 4.1.x tree (what's
currently CVS HEAD) on your dev. environments and file any bugs against
it so we can get it closer to release.

Jim Davidson is still sitting on a bunch of changes to the conn handling
stuff and I have a feeling as time passes he's touching more and more of
the code ... so we might see another large check-in from him before
4.1.0 is ready.

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] 
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: 
field of your email blank.