Caching requests with a transient NIK

[Christian Biesinger]

Hello!

I am following up on this post from some time ago:
https://groups.google.com/a/chromium.org/g/net-dev/c/bfmJbqSUODI/m/fvsTUSaaAgAJ

Is it still correct that the networking stack does not cache requests
made with a transient NIK?

In our situation (the FedCM API), we make a couple of requests with a
transient NIK whenever a website calls our API. This is to request
public files, including a /.well-known file. We would ideally like to
cache these (according to whichever cache-control headers were sent)
because they rarely change and it would speed up our API in a number
of common cases.

Is it now possible to cache such requests?

Thanks!
Christian

[Matt Menke]

Correct - requests with transient NIKs are not cached.  Note that creating a transient NIK effectively creates an entirely new network partition, so even if we did cache, the exact same transient NIK would need to be used for both requests.

If the same transient NIK were used with two different URLs (or the same URL, of course), of course, the server could cross-correlate those URLs based on various bits of metadata.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAPTJ0XHCK12gwG9F3vc8W6fgFSYMp2q_sq3SXkJkOFgUkG50VQ%40mail.gmail.com.

[Christian Biesinger]

Is there a way to generate a NIK that would be separate from regular
cookies/etc but would allow caching? Let's say a fixed "FedCM" NIK (I
am not sure if NIKs are strings...)

For the moment let's assume that the cross-correlation is fine (I will
have to think about this...)


Christian

[Matt Menke]

No, there's not.  Relevant code is at https://source.chromium.org/chromium/chromium/src/+/main:net/http/http_cache.cc;l=631;drc=7c06a7a69d82892b8cd7446ed04e200dfed9eeae;bpv=0;bpt=1

You could imagine adding a new bit to persist "transient" NIKs, or, perhaps more reasonable in terms of terminology, to create isolated (unique?) persisted NIKs, but that's not available today.  I think if we were to provide such an API, may warrant some discussion if that's something we want to do, just in terms of thinking about usage patterns where it may be reasonable, and where it should be discouraged, and if there are enough of the latter to not be worth the benefit of the former.

There are two separate ways to make transient NIKs (opaque origins and nonces), so would have to think about how such a putative new bit would interact with each of those as well.