Sending Client hint headers to API server

Question

It seems with the ClientHint API being newer, there isn't a lot of information available on this topic. I've read dozens of articles and, at this point, I'm missing some key details in the implementation requirements.

Here is the scenario. We have many frontend apps that make GraphQL requests (POST) to our API server. This server is hosted on a different domain than our frontend apps.

Through my research, I'm seeing that using the meta tag for delegate-ch, I should be able to delegate the client hint headers to the API server domain, like so:

<meta
      http-equiv="delegate-ch"
      content="sec-ch-ua http://api.foo.test; sec-ch-ua-model http://api.foo.test; sec-ch-ua-platform http://api.foo.test; sec-ch-ua-platform-version http://api.foo.test; sec-ch-ua-mobile http://api.foo.test"
/>

Unfortunately, that's not working. I've tried adding the accept-ch meta tag as well, but I believe that's unnecessary. I've also tried appending the /graphql path to the urls, as that's the actual path for GraphQL API requests. None of that helps.

Additionally, our API server is returning the Accept-Ch and Critical-Ch response headers on OPTIONS requests (all requests for that matter). I understand this may not working since this isn't the origination domain. Would be great if it respected it though.

So, is this a POST request issue? What's the issue here? We're at a point now where User-Agent headers are frozen and no longer reliable.

This is being tested on Chrome 116 which should have full support and no privacy settings modifications that I'm aware of. I have also been able to confirm that the headers are being passed on other sites with GET requests where the response headers are requesting it - using this same Chrome instance.

Answer 1

Someone is surely going to come across this post with the lack of information available. After much digging and reading on the spec, the issue is that the client hint headers are only sent with https requests. This is obvious as it's a privacy consideration. Unfortunately, that means you're going to have to support https in your dev environment if you want to get any reasonable testing done.

POST requests are supported as well.

Ultimately, you have to either delegate the headers using a meta tag on the original domain executing the requests (delegate-ch). Or include Permissions-Policy response header on the same domain authorizing and suggesting the headers be sent to the defined domains with the request.

https://web.dev/migrate-to-ua-ch/#strategy-delegating-hints-to-cross-origin-requests

If you're making API requests, like is the case for us, you probably don't need to include any headers on the actual API server. The headers are tied to the request/response with the frontend application. The Permissions-Policy or the delegate-ch meta tag, tell the browser which domains/servers to share these headers with.

We ended up going with headers instead of a meta tag, as that gives us better control with regards to frontend devs breaking the implementation requirements.