Gisle,
The more I'm thinking about it, it's not appropriate for LWP. As far as
I can think of, this would be the first and only instance of LWP
modifying content that it receives before passing it back to the caller.
I'm not sure that's a direction we should go.
I agree. There are
---BeginMessage---
Brian Cassidy [EMAIL PROTECTED] writes:
Also, there needs to be something selectable for the users who happen to
have Compress::Zlib but don't want to get compressed data for whatever
reason.
It would certainly not happen by default. If you download a .tar.gz
Gisle,
Doh. Way to ruin my day! :)
So, are there any proposed work-arounds, or is this completely useless now?
-Brian
-Original Message-
No. A server does the right thing if it marks a gziped file tar file
with Content-Encoding: gzip. Some examples:
http://www.gordano.com -
David Carter [EMAIL PROTECTED] writes:
My understanding had always been that content-encoding (when talking about
compression) is in practical terms no different than transfer-encoding. LWP
already handles transfer-encoding (gzip or deflate), so what's the big deal
about it also handling
Brian Cassidy [EMAIL PROTECTED] writes:
So, are there any proposed work-arounds, or is this completely useless now?
The decompresser just needs to be smarter about when to kick in. For
a GUI browser it would kick in if you decide to display the document.
This can be determined after looking at
From the redirects thread also on this list, I find the
browser test suite site Brian mentioned to be relevant
to this dicusssion.
Shouldn't LWP be able to handle this URL automagically?
(Whether by default or not is, as always, open to
discussion.)
[EMAIL PROTECTED] writes:
Shouldn't LWP be able to handle this URL automagically?
Yes, if we can find an API everybody is happy with.
http://diveintomark.org/tests/client/http/200_gzip.xml
IE just does it.
So does Mozilla. Konqueror suggest saving or opening the file in an
external app,
On Wed, 3 Dec 2003, Gisle Aas wrote:
[EMAIL PROTECTED] writes:
[...]
http://diveintomark.org/tests/client/http/200_gzip.xml
IE just does it.
[...]
Konqueror suggest saving or opening the file in an
external app, but the file saved or given to an external app is still
gzipped.
Not in
On Wed, 3 Dec 2003, John J Lee wrote:
[...]
Not in KDE 3.2: it decompresses automatically, so when you save or open
with KWrite, it's just 200_gzip.xml.
...and I'd take a guess that's because Safari (Apple's browser based on
Konqueror) does the same, because 3.2 apparently includes a lot of
Don't you also need to adjust the content-length header
to match the new (uncompressed) content?
---
David Carter
[EMAIL PROTECTED]
On Tue, 2 Dec 2003 13:37:06 -0400, Brian Cassidy
wrote:
Hi All,
Today I cooked up a little bit of code [1] to give
WWW::Mechanize the
ability to handle
]
Sent: Tuesday, December 02, 2003 1:57 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: RFC: WWW::Mechanize::Compress or LWP patch?
Don't you also need to adjust the content-length header
to match the new (uncompressed) content?
---
David Carter
[EMAIL PROTECTED]
On Tue, 2 Dec
Brian - Had I read your code more closely, I would have
seen this! I agree with you that handling this at the
LWP layer makes more sense than handling it in
Mechanize.
---
David Carter
[EMAIL PROTECTED]
On Tue, 2 Dec 2003 14:07:43 -0400, Brian Cassidy
wrote:
In my WWW::Mech sub-class, I'm not
Brian - Had I read your code more closely, I would have
seen this! I agree with you that handling this at the
LWP layer makes more sense than handling it in
Mechanize.
The more I'm thinking about it, it's not appropriate for LWP. As far as
I can think of, this would be the first and only
Andy Lester [EMAIL PROTECTED] writes:
Brian - Had I read your code more closely, I would have
seen this! I agree with you that handling this at the
LWP layer makes more sense than handling it in
Mechanize.
The more I'm thinking about it, it's not appropriate for LWP. As far as
I can
14 matches
Mail list logo
