bug-wget
[Top][All Lists]
Advanced

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

Re: wget2 server-response


From: Tim Rühsen
Subject: Re: wget2 server-response
Date: Sun, 15 Sep 2024 18:27:37 +0200
User-agent: Mozilla Thunderbird

Hey Hans, thanks for reaching out.

Indeed, it looks like HTTP/1.1 response headers see a regression while HTTP/2 response headers are printed as expected (tested with latest master). This requires a fix.

Also, currently on Fedora 40, the progress bar takes preference over the other output. The latest master of wget2 is somewhat improved, but still needs more fine-tuning.

Likely, your best option is to turn the progress bar off with `--progress=none`.

With HTTP/2:

$ wget2 --server-response --progress=none https://example.com
[0] Downloading 'https://example.com' ...
Saving 'index.html.1'
# got header 362 bytes:
:status: 200
content-encoding: gzip
accept-ranges: bytes
age: 249375
cache-control: max-age=604800
content-type: text/html; charset=UTF-8
date: Sun, 15 Sep 2024 16:14:45 GMT
etag: "3147526947+gzip"
expires: Sun, 22 Sep 2024 16:14:45 GMT
last-modified: Thu, 17 Oct 2019 07:18:26 GMT
server: ECAcc (nyd/D14D)
vary: Accept-Encoding
x-cache: HIT
content-length: 648

HTTP response 200  [https://example.com]

With HTTP/1.1 (almost all headers missing):

$ wget2 --server-response --progress=none --no-http2 https://example.com
[0] Downloading 'https://example.com' ...
Saving 'index.html.4'
# got header 381 bytes:
HTTP/1.1 200 OK
Content-Encoding: gzip
HTTP response 200 OK [https://example.com]

Thanks for the report!

Regards, Tim


On 8/25/24 20:02, Hans Carlson via Primary discussion list for GNU Wget wrote:
I recently installed Fedora 40 and was a bit confused by the wget output... it seemed different.  After a bit of testing, I found the --server-response (-S) option didn't seem to work at all.  I downloaded the old wget (1.24.5), compiled and tested and got the results I expected.

Was the --server-response option not implemented in wget2 (it does show in the --help and man page).  Or is this a known bug?  Or am I doing something wrong?

See output for both wget2 and wget1 below.

-------------------------------------------------------------------------
wget2 output

   $ /usr/bin/wget --version | head -n1
   GNU Wget2 2.1.0 - multithreaded metalink/file/website downloader
   $ /usr/bin/wget --server-response example.com
  index.html.2         100% [========================================================================================================================================================================================>]     648     --.-KB/s                             [Files: 1  Bytes: 648  [35.15KB/s] Redirects: 0  Todo: 0  Errors: 0

-------------------------------------------------------------------------
wget1 output

   $ /usr/local/bin/wget --version | head -n1
   GNU Wget 1.24.5 built on linux-gnu.
   $ /usr/local/bin/wget --server-response example.com
   --2024-08-25 10:24:12--  http://example.com/
  Resolving example.com (example.com)... 93.184.215.14, 2606:2800:21f:cb07:6820:80da:af6b:8b2c
   Connecting to example.com (example.com)|93.184.215.14|:80... connected.
   HTTP request sent, awaiting response...
     HTTP/1.1 200 OK
     Accept-Ranges: bytes
     Age: 254500
     Cache-Control: max-age=604800
     Content-Type: text/html; charset=UTF-8
     Date: Sun, 25 Aug 2024 17:24:12 GMT
     Etag: "3147526947+gzip"
     Expires: Sun, 01 Sep 2024 17:24:12 GMT
     Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
     Server: ECAcc (sed/58CB)
     Vary: Accept-Encoding
     X-Cache: HIT
     Content-Length: 1256
   Length: 1256 (1.2K) [text/html]
   Saving to: ‘index.html.3’

  index.html.3 100%[=======================================================================================================================================>]   1.23K  --.-KB/s    in 0s

   2024-08-25 10:24:12 (339 MB/s) - ‘index.html.3’ saved [1256/1256]

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


reply via email to

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