Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upDefining goals, deprecating the User-Agent string, and how server implementations would actually work #14
Comments
This comment has been minimized.
This comment has been minimized.
|
That was rather rambling, so maybe it would help if I now simplify it down to some individual questions...
|
This comment has been minimized.
This comment has been minimized.
|
Can you please elaborate on 2. (and 5.)? Why is UA data a session-level thing? |
This comment has been minimized.
This comment has been minimized.
|
It's difficult to answer that, as it really depends how things end up being implemented. If it's implemented that the client will send the superset of headers requested by anything on the domain, forever, then unless you are writing some analytics system that needs to back-associate detailed user agent data to the first request, you don't need to track this stuff in sessions. However, if there's the possibility of the data being narrowed in the future, webapps are likely to want to hold onto the data in sessions, depending on what they are trying to do, and depending on what data is guaranteed to be available initially. Here's an example... (Or they could use JavaScript and build up their page that way of course). I feel I am getting stuck in a deep web of hypotheticals. I could talk for hours about all the different use cases and how things might turn out depending on implementation choices. |
This spec seems to be achieving a few things at once, which is great, but I think we could use some clarity on what these things are and how the spec should be implemented to achieve them. I see it as:
Achieving the second goal seems like a longer term thing, but actually I don't think it has to be. If the server passes a
Accept-CHheader, I think it would be fair to omit the old-school user-agent header entirely for future requests. If this is going to be the case though, I think it should be decided early so implementations are consistent.Beyond the above, there is a major paradigm shift in this specification that brings up some important issues.
I could suggest solutions to these problems, but the solutions will likely be limiting in terms of how well the defined goals would be achieved. For example, we could say that the UA sends the superset of everything requested with every future request, but this would go against a desire to improve performance. Or we could specify that the UAs continue to send a superset of everything, until it is acknowledged as received and handled by the webapp.
So I think there's a lot of thought that needs to go into exactly how these issues are going to be handled. It's getting complicated!