Deprecate Accept-Charset

[annevk]

It's my understanding that the IETF recommends exclusive use of UTF-8. It seems therefore that Accept-Charset can go. (Browsers already do this and Fetch requires it, FWIW.)

[reschke]

Please clarify what exact change you are proposing.

FWIW, I agree that exclusive use of UTF-8 is preferrable, but this is not a new protocol. We can not "un-define" this header field. We could add prose explaining why it's still there, and why it may be bad to base new HTTP applications on it. Thinking of it, this might be input for BCP56bis?

[annevk]

You can recommend user agents to not send it and servers not to rely on it existing.

[reschke]

The latter part is already covered by the spec, no?

WRT former, I certainly agree for browsers, but again, this is a 25 year old protocol, and there may be legitimate uses in the wild.

[mnot]

We can deprecate it, we've done that elsewhere.

[reschke]

It's fully optional. I don't see any merit in deprecation. We can explain why it's less important than 25 years ago, though.

[mnot]

It's also fingerprinting surface area. That's a security/privacy concern, which changes things a bit.

[reschke]

Well, the header field can't "go". It has a defined meaning and it is in use, and that should be documented.

We can advise against it's use, if that's what you mean by "deprecating".

[reschke]

FWIW, we should document fingerprint surface in general for all request header fields (the recent discussion about webp comes to mind).

[mnot]

I don't think that was proposed. I think what's on the table is:

• Putting some prose in explaining the downsides, and
• Changing its status in the registry to "obsoleted."

[mnot]

+1 to that. I've just added some text to BCP56bis asking applications to consider that, but specific guidance for headers would be great.

[reschke]

The User-Agent header field might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, particularly if the user agent sends excessive details about the user's system or extensions. However, the source of unique information that is least expected by users is proactive negotiation (Section 5.3), including the Accept, Accept-Charset, Accept-Encoding, and Accept-Language header fields.

-- https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.9.7.p.3

[mnot]

Discussed in Montreal; support for documenting problems (fingerprinting and lack of usefulness), obsoleting in registry. Can probably remove some text too.