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 ch
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
[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
>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.)
http://diveintomark.org/tests/client/http/200
Hi all,
I sometimes gets <$tag> outside warnings when using HTML::Form
(via WWW::Mechanize).
The code in HTML::Form that issues this warning is:
Carp::carp("<$tag> outside ") if $^W;
The problem is, if I suppress this warning, I have to suppress all
warnings and I'd rather not do that.
Wh
> -Original Message-
> And how to handle 300 responses is not really well defined in RFC 2616
> either. It says that the "entity" will contain a list of resources
> that the user agent can choose between. It then goes on to say that
> there might also be a Location field containing the s
"Brian Cassidy" <[EMAIL PROTECTED]> writes:
> > -Original Message-
> > What do you think it should do exactly?
>
> I would say... redirect!
>
> At least, since the RFC (2616, see section 6.1.1, last paragraph) says that
> all unknown status codes are to be handled by the base code (ie 32
> -Original Message-
> What do you think it should do exactly?
I would say... redirect!
At least, since the RFC (2616, see section 6.1.1, last paragraph) says that
all unknown status codes are to be handled by the base code (ie 320 => 300),
then those unknown 3XX codes should redirect. Co
"Brian Cassidy" <[EMAIL PROTECTED]> writes:
> Playing around with some test response codes, I've found that (at least) 300
> (multiple choices) and 320 (bogus) do not redirect, even though they fall
> under is_redirect().
What do you think it should do exactly?
I don't really feel like doing any
Since I have your attention... :)
Playing around with some test response codes, I've found that (at least) 300
(multiple choices) and 320 (bogus) do not redirect, even though they fall
under is_redirect().
Traces:
--
LWP::UserAgent::new: ()
LWP::UserAgent::request: ()
LWP::UserAgent::send_reque
"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 lookin
"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 handli
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
--- Begin Message ---
"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 dow
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 content-encoding compression in a transparent man
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. The
16 matches
Mail list logo
