[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] wget option "-p" incompatible with compression?

From: Giuseppe Scrivano
Subject: Re: [Bug-wget] wget option "-p" incompatible with compression?
Date: Sun, 25 Apr 2010 16:32:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Jens Schleusener <address@hidden> writes:

> (for the Germans: Giuseppe spoken Tschuseppe ?)

It is more like: Jewseppee 

This can help you better:


> Ok, that I was afraid. Maybe that should be mentioned shortly in the
> man page under the "--page-requisites" documentation.

Thanks for the hint.

> P.S.: OT: I "misused" wget for some kind of (relative) benchmarking to
> check the performance of some different configurations of an
> self-administrated Apache/Varnish system. Anyone knows a "simple"
> (batch) tool to "simulate" real browser behaviour for that purposes?
> My current test approach using Firefox with Firebug/PageSpeed and/or
> Wireshark is probably realistic but a little bit troublesome.

I think these tools can help you:

By the way, a "real" browser doesn't do quickly many requests but there
are quite long intervals where the connection is kept alive without any
request to the server.


>> Jens Schleusener <address@hidden> writes:
>>> Hi,
>>> sorry, the below described wget behaviour may not be a real bug:
>>> I use often the wget option
>>>  --page-requisites
>>> ("-p") but for some test purposes I now added also the option
>>>  --header='Accept-Encoding: gzip, deflate'
>>> Now wget downloads and saves for e,g, a file named index.html (not
>>> index.html.gz) but in "gzip compressed" format. But wget doesn't seem
>>> to detect that and so cannot find other files that are necessary to
>>> properly display the given HTML page. Any hints to circumvent that
>>> behaviour respectively to force decompression of compressed files
>>> after download?
>>> Regards
>>> Jens

reply via email to

[Prev in Thread] Current Thread [Next in Thread]