#1107103 w3m: cannot parse HTTP/1.1 response from GitHub - "gzip: stdin: not in gzip format"

Package:
w3m
Source:
w3m
Description:
WWW browsable pager with excellent tables/frames support
Submitter:
Vincent Lefevre
Date:
2025-07-02 11:35:02 UTC
Severity:
normal
Tags:
#1107103#5
Date:
2025-06-01 15:45:35 UTC
From:
To:
When trying to open github.com URLs, w3m gives

  gzip: stdin: not in gzip format

In a comment in the upstream bug, Rene Kita says that the cause is
that "GitHub is ignoring the http/1.0 request and sending an http/1.1
response which w3m cannot parse" and provides a workaround consisting
in using a CGI script that invokes curl on the URL (via site-specific
settings).

#1107103#10
Date:
2025-07-02 07:32:55 UTC
From:
To:
It looks like Salsa also requires HTTP/1.1+ now?

How hard is it to "just" make w3m speak HTTP/1.1?
I seem to recall 1.0 and 1.1 are pretty similar.

I just ran "dman logcheck" (with PAGER=w3m) and followed the link to
https://salsa.debian.org/debian/logcheck, but it silently failed to
change page.

$ curl -sSfL --http1.0 https://salsa.debian.org/debian/logcheck | file -
curl: (35) OpenSSL/3.0.16: error:0A00006E:SSL routines::bad extension
/dev/stdin: empty

$ curl -sSfL --http1.1 https://salsa.debian.org/debian/logcheck | file -
/dev/stdin: HTML document, Unicode text, UTF-8 text, with very long
lines (9923)

Testing was done on Debian 12.

#1107103#15
Date:
2025-07-02 11:00:10 UTC
From:
To:
Anyway what you are seeing here is a bug in curl: it puts an alpn
extension into the request, and for --http1.0 the value is
"http/1.0". I doubt this is a valid value.
Indeed curl from trixie (even with --http1.0) sets alpn=http/1.1,
and salsa correctly returns a reply.

You can also see this in curl's output if run it with -vv:
...
* ALPN: offers http/1.0
...
* OpenSSL/3.0.16: error:0A00006E:SSL routines::bad extension

Anyway, none of that is relevant for w3m TTBOMK.

Chris

#1107103#20
Date:
2025-07-02 11:32:21 UTC
From:
To:
My fault.

w3m didn't work, so I cross-checked with curl, which also didn't work
for http 1.0 (but did for http 1.1).

So I guessed that meant salsa was broken for http 1.0, and mentioned it
on the "w3m can't do github because w3m is http 1.0" bug.

It didn't occur to me that curl might fail for unrelated reasons.

Further testing shows that
"w3m https://salsa.debian.org/debian/logcheck" works, but
"dman logcheck" then clicking (^I^M) the same link fails, with error message
"Can't load https://salsa.debian.org/debian/logcheck"

I don't know what's going on there, but I agree it's not relevant to
1107103 (w3m HTTP/1.0 client is too old for github.com).

Sorry for the noise.