Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should Sec-UA-Arch define canonical names for popular architectures, or have a registry? #61

Closed
othermaciej opened this issue Feb 6, 2020 · 3 comments · Fixed by #106

Comments

@othermaciej
Copy link

In current user agent strings, it's hard to make use of CPU architecture without reference to platform.

For example, popular browser UA strings refer to the x86-64 architecture as x86_64 on Linux, x64 on Windows, and Intel on Macs. To make it reasonable and useful to request Sec-UA-Arch by itself, there probably needs to be a consistent name for any given CPU architecture. To achieve this, the spec either needs to predefine some, or point to a registry.

You could just say that browsers ought to use whatever architecture name they send in the UA string, and clients just have to deal with multiple synonyms for the same architecture, but that misses a potential one-time opportunity for a useful cleanup.

(Note though that in #58 I suggest dropping this field, or allowing it to be blank or fictional, for browsers that chose not to expose the true CPU architecture at all.)

@mcatanzaro
Copy link

For example, popular browser UA strings refer to the x86-64 architecture as x86_64 on Linux, x64 on Windows, and Intel on Macs.

Or on FreeBSD: amd64

@tresf
Copy link

tresf commented May 21, 2020

Or on FreeBSD: amd64

I've made this similar point here: https://github.com/WICG/ua-client-hints/pull/106/files#r428897514 (Edit: Github won't link a resolved conversation, you'll have to expand and scroll, sorry).

@othermaciej
Copy link
Author

Agreed that this is resolved by #106.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants