You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, service at delegated-ipfs.dev/routing/v1 sends CORS header only when Origin header is present in the request, and when Origin is present, the response has Vary: Origin:
If the Vary header in response is set to value Origin, it indicates that the response may vary depending on the value of the Origin header in the request.
It means the response is reusable (cacheable) only as long value in Origin header matches, so responses for requests made from different websites (origins) won't benefit from caching.
IIUC this makes little sense with access-control-allow-origin: * because we want liberal access to public goods, and we don't have site-specific responses, so we want cache to be shared across websites that use public goods to maximize cache HIT rate:
👉 We want CID lookup done by JS running on https://one.example.com to be returned from cache when https://two.example.net asks for it.
Solution
Trustless public good services must have a global cache that is shared across websites (no matter what is in Origin), which means we don't want Vary: Origin at
delegated-ipfs.dev (needs fixing)
trustless-gateway.link (already ok, but mentioning here as it should share the config/setup/tests)
TODO
adding CORS, Vary, and HTTP Caching to our HTTP specs is tracked in gateway: add CORS to specs ipfs/specs#423 (added /routing/v1 items there, consider out of scope here)
remove Vary: Origin from delegated-ipfs.dev responses
Caveat: be careful to not remove Vary: Accept-Encoding which is used by compression
I suspect delegated-ipfs.dev regression was introduced when we added github.com/rs/cors to someguy (add http handlers for cors, metrics and compression ipfs/someguy#30). An easy fix may be to remove that library and instead hardcode liberal CORS headers on all response types.
The text was updated successfully, but these errors were encountered:
@ns4plabs I am not sure how easy it will be to fix in someguy without having to modify the github.com/rs/cors library (imo it should not send Vary: Origin if CORS is effectively disabled/lifted by *).
I it helps, I think for this specific project (someguy) hardcoding liberal CORS on all GET|HEAD|POST|OPTIONS responses is fine. Are you able to add this to your queue and ping me or @hacdias for review?
Right now, service at
delegated-ipfs.dev/routing/v1
sends CORS header only whenOrigin
header is present in the request, and whenOrigin
is present, the response hasVary: Origin
:Problem
If the
Vary
header in response is set to valueOrigin
, it indicates that the response may vary depending on the value of the Origin header in the request.It means the response is reusable (cacheable) only as long value in
Origin
header matches, so responses for requests made from different websites (origins) won't benefit from caching.IIUC this makes little sense with
access-control-allow-origin: *
because we want liberal access to public goods, and we don't have site-specific responses, so we want cache to be shared across websites that use public goods to maximize cache HIT rate:👉 We want CID lookup done by JS running on
https://one.example.com
to be returned from cache whenhttps://two.example.net
asks for it.Solution
Trustless public good services must have a global cache that is shared across websites (no matter what is in
Origin
), which means we don't wantVary: Origin
atdelegated-ipfs.dev
(needs fixing)trustless-gateway.link
(already ok, but mentioning here as it should share the config/setup/tests)TODO
Vary: Origin
fromdelegated-ipfs.dev
responsesVary: Accept-Encoding
which is used by compressiondelegated-ipfs.dev
regression was introduced when we added github.com/rs/cors to someguy (add http handlers for cors, metrics and compression ipfs/someguy#30). An easy fix may be to remove that library and instead hardcode liberal CORS headers on all response types.The text was updated successfully, but these errors were encountered: