Overly prescriptive request header fields #284
Comments
|
Hi @ronancremin. The User-Agent field will still exist, and UAs (be they browsers, bots, scripts) are still free to send them - this spec makes no requirements on what it should look like. The latest IETF RFC that defines User-Agent (https://datatracker.ietf.org/doc/html/rfc7231#section-5.5.3) has some useful SHOULD-level guidance on what to send and what not to send.
Can you give an example of what you're describing here? |
|
In descriptions of UA-CH it is generally pitched as a partial or full replacement for the current User-Agent header e.g.
But much current active usage of the User-Agent header includes granular information about libraries, subcomponents and so on (as specified by RFC7231) that doesn't fit into the list of headers defined by the UA-CH proposal:
If UA-CH really is to become the mechanism for controlling granular details exposed by user agents it should better accomodate current use cases. If not, we will end up with a situation where both the standard RFC7231 User-Agent headers and proposed UA-CH headers are in used in perpetuity, resulting in a significant increase in complexity for developers and publishers. The intended scoping of this proposal is possibly germane. #219 |
|
Hi @ronancremin, thanks for the examples. AFAICT, all of these could be covered by the existing client hints, were these UAs interested in sending them. It seems like a lot of things could just end up in the brand list, or the full-version list. Here's an example, Whatever this is: Sec-CH-UA: “QPExoPlayer”; v=3, “ExoPlayerLib; v=2” |
|
In my mind the spec's usage of the brand list was to allow a user agent to include several brands for itself e.g. "Google Chrome" and "Chromium" or "Microsoft Edge" and "Chromium" as currently seen in active use. Using a brand list to communicate constituent components or libraries feels awkward, or a dissonantly named header at the very least. I don't think anyone looking at the ExoPlayerLib/2.9.4, libhttp/1.000 or libwww/2.17b3 tokens in a user-agent strong thinks "brands" in the normal sense of the word. These are components (or "significant subproducts" to use the term from rfc7231) more than they are a particular name or identity, and they map awkwardly into a "brand list" IMHO. |
|
Agree - I wouldn't consider "libhttp" to be a brand. We do allow an "equivalence class" to be in the brand list, however. I don't see much of a difference between "libhttp/1.000" or "libwwww/2.17b3" and "Gecko 100" or "Chromium 100". |
|
The spec defines equivalence class as representing:
The intent of this seems to be a very specific and narrow use case around compatibility and not at all semantically similar to communicating significant subproducts. If the brands list idea was named differently e.g. "significant subproducts" and described more generally I think it would all make a lot more sense, and more fully incorporate usage patterns suggested in the original RFCs as well as those seen in the wild today. |
As originally envisaged in HTTP 1.0, HTTP 1.1 etc., the User-Agent header "consists of one or more product identifiers, each followed by zero or more comments which together identify the user agent software and its significant subproducts."
This open-ended mechanism allowed user agents to decide how much detail to reveal about subproducts. The example cited in the RFCs illustrates this usage, where the user agent choses to identify itself, its version and details of a constituent library:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3The UA-CH proposal by comparison is tightly prescriptive in the semantics of what user agents can chose to reveal about themselves. The Sec-CH-UA headers focus on a very narrow set of predefined fields leaving no natural place to express details such as constituent libraries, components and their versions.
This appears to result in a reduction of usefulness. The User-Agent header is currently used constructively to communicate limitations and capabilities of the user agents. A proposed replacement should not remove functionality that user agents chose to avail of.
The text was updated successfully, but these errors were encountered: