4 ms·

I wonder if it'd be too late for http/3 to say "user-agent is deprecated, user-agents should not send it, any server accepting http/3 may assume the following c

I wonder if it'd be too late for http/3 to say "user-agent is deprecated, user-agents should not send it, any server accepting http/3 may assume the following compatibility value for the header without it being sent". Was anything like that considered during the http/3 design process? (I saw the linked "client hints" proposal in the article, but that doesn't mention the idea of completely dropping the header from client requests and assuming a certain baseline value for http/3.)

toast0 7y ago
User-Agent for browsers is pretty much useless now, but it's still a pretty useful name for a header if you want to put real information in it. Ex, if you're calling an api, it's nice to have a version number and a name/contact so broken things can be fixed. I don't remember if HTTP/2 (and presumably /3) has a initial dictionary for header compression, they could have a suggested value in there, so if you want to look like a browser, you can use that at a low byte cost.
- edoceo 7y ago
  I make an API, for narrow use case. All calls have to be from a registered UA, among other things forms the HMAC sig.
  - sk5t 7y ago
    You have created a perverse-sounding design.
  - neikos 7y ago
    This sounds like authentication with extra steps? Why not just send a bearer token?
    - edoceo 7y ago
      We do. Header is for message signing. And UA has to be registered, part of the spec provided by client.
denormalfloat 7y ago
This would not work, too many websites (perhaps wrongly) depend on this string.
- JoshTriplett 7y ago
  I'm specifically suggesting that http/3 could have an implied value for this header if not supplied, so that omitting it was semantically equivalent (and a server could synthesize it).
  - denormalfloat 7y ago
    That's not how HTTP works. HTTP is a transfer protocol, and is not so opinionated on the semantic meaning of the Data it moves. HTTP, HTTP/2, and HTTP/3 were designed to be backwards compatible. It would break that compatibility if there were a semantic change in the absence of the UA string. Specifically, H/3 requests couldn't be downgraded to HTTP/1.1 requests by proxies. There are a lot of proxies.
    - JoshTriplett 7y ago
      > It would break that compatibility if there were a semantic change in the absence of the UA string. Specifically, H/3 requests couldn't be downgraded to HTTP/1.1 requests by proxies. It would not reduce the semantic meaning of HTTP to say "in http/3, the default value of the user-agent header is XYZ (a non-specific modern browser), and if you want an empty header, you must specify the header with an empty value. Proxies and other software translating requests between http/3 and older versions of http should map an omitted header in http/3 to this value, and should map an empty string to a missing header." It would certainly require change, and it isn't a change likely to happen at this point, but it wouldn't have been impossible, nor would it have reduced the fidelity of http. It simply would have changed the default assumption from "something too ancient to identify itself" to "something modern that doesn't want to identify itself".

toast0 7y ago

User-Agent for browsers is pretty much useless now, but it's still a pretty useful name for a header if you want to put real information in it. Ex, if you're calling an api, it's nice to have a version number and a name/contact so broken things can be fixed. I don't remember if HTTP/2 (and presumably /3) has a initial dictionary for header compression, they could have a suggested value in there, so if you want to look like a browser, you can use that at a low byte cost.

edoceo 7y ago
I make an API, for narrow use case. All calls have to be from a registered UA, among other things forms the HMAC sig.
- sk5t 7y ago
  You have created a perverse-sounding design.
- neikos 7y ago
  This sounds like authentication with extra steps? Why not just send a bearer token?
  - edoceo 7y ago
    We do. Header is for message signing. And UA has to be registered, part of the spec provided by client.

denormalfloat 7y ago

This would not work, too many websites (perhaps wrongly) depend on this string.

JoshTriplett 7y ago
I'm specifically suggesting that http/3 could have an implied value for this header if not supplied, so that omitting it was semantically equivalent (and a server could synthesize it).
- denormalfloat 7y ago
  That's not how HTTP works. HTTP is a transfer protocol, and is not so opinionated on the semantic meaning of the Data it moves. HTTP, HTTP/2, and HTTP/3 were designed to be backwards compatible. It would break that compatibility if there were a semantic change in the absence of the UA string. Specifically, H/3 requests couldn't be downgraded to HTTP/1.1 requests by proxies. There are a lot of proxies.
  - JoshTriplett 7y ago
    > It would break that compatibility if there were a semantic change in the absence of the UA string. Specifically, H/3 requests couldn't be downgraded to HTTP/1.1 requests by proxies. It would not reduce the semantic meaning of HTTP to say "in http/3, the default value of the user-agent header is XYZ (a non-specific modern browser), and if you want an empty header, you must specify the header with an empty value. Proxies and other software translating requests between http/3 and older versions of http should map an omitted header in http/3 to this value, and should map an empty string to a missing header." It would certainly require change, and it isn't a change likely to happen at this point, but it wouldn't have been impossible, nor would it have reduced the fidelity of http. It simply would have changed the default assumption from "something too ancient to identify itself" to "something modern that doesn't want to identify itself".