help-gnu-emacs
[Top][All Lists]
Advanced

[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.



reply via email to

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