[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs-w3m question
From: |
Yuri Khan |
Subject: |
Re: emacs-w3m question |
Date: |
Mon, 7 Nov 2022 13:59:26 +0700 |
On Mon, 7 Nov 2022 at 13:47, Stefan Monnier via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> Yuri Khan [2022-11-07 13:08:44] wrote:
> > After re-reading RFC 9110 § 12.5.3, it looks like the client should
> > indicate its supported and preferred content encodings in an
> > Accept-Encoding request header. Does w3m.el send one? If it doesn’t,
> > the server may assume any encoding is acceptable.
>
> Really? That doesn't sound right. Shouldn't the server assume that
> only the simplest encodings can be used if the header is missing?
> That's the only safe choice, no?
Yeah, my intuition also said so and I was about to compose a reply of
indignant finger pointing at the sites that spew brotli without any
indication that the client would be able to process it, but I decided
to look up the spec and changed my mind.
This is what it says, after explaining the syntax:
: A server tests
: whether a content coding for a given representation is acceptable
: using these rules:
:
: 1. If no Accept-Encoding header field is in the request,
: any content coding is considered acceptable by the user agent.
: 2. If the representation has no content coding,
: then it is acceptable by default
: unless specifically excluded by the Accept-Encoding header field
: stating either "identity;q=0" or "*;q=0"
: without a more specific entry for "identity".
: 3. If the representation's content coding is one of the content codings
: listed in the Accept-Encoding field value,
: then it is acceptable unless it is accompanied by a qvalue of 0.
: (As defined in Section 12.4.2,
: a qvalue of 0 means "not acceptable".)
I checked and similar wordings run back through the original HTTP/1.1
spec (RFC 2616). That version also includes the following:
: Note: If the request does not include an Accept-Encoding field,
: and if the "identity" content-coding is unavailable, then
: content-codings commonly understood by HTTP/1.0 clients (i.e.,
: "gzip" and "compress") are preferred; some older clients
: improperly display messages sent with other content-codings. The
: server might also make this decision based on information about
: the particular user-agent or client.
- Re: emacs-w3m question, (continued)
- Re: emacs-w3m question, Emanuel Berg, 2022/11/02
- Re: emacs-w3m question, Jon Fineman, 2022/11/02
- Re: emacs-w3m question, Emanuel Berg, 2022/11/03
- Re: emacs-w3m question, Bob Newell, 2022/11/03
- Re: emacs-w3m question, Jon Fineman, 2022/11/03
- Re: emacs-w3m question, Bob Newell, 2022/11/06
- Re: emacs-w3m question, Yuri Khan, 2022/11/07
- Re: emacs-w3m question, Bob Newell, 2022/11/07
- Re: emacs-w3m question, Stefan Monnier, 2022/11/07
- Re: emacs-w3m question,
Yuri Khan <=
- Re: emacs-w3m question, Emanuel Berg, 2022/11/07
- Re: emacs-w3m question, Emanuel Berg, 2022/11/08
Re: emacs-w3m question, Bob Newell, 2022/11/02