-
Notifications
You must be signed in to change notification settings - Fork 150
feat(gateway): IPIP-523 format query over Accept header #1074
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
Conversation
…pt header this change simplifies precedence rules by making the ?format= URL query parameter always take priority over the Accept HTTP header when both are present. in practice, this is largely compatible with existing browser use cases since browsers send Accept headers with wildcards which were already treated as non-specific. prioritizing ?format= also ensures deterministic HTTP caching behavior, protecting against CDNs that comingle different response types under the same cache key. the only breaking change is for edge cases where a client sends both a specific Accept header and a different ?format= value. previously Accept would win, now ?format= wins. this scenario is rare and arguably represents client misconfiguration. when detected, gateway returns HTTP 400 to signal the ambiguity. specs: ipfs/specs#523 tests: ipfs/gateway-conformance#252
Codecov Report❌ Patch coverage is
@@ Coverage Diff @@
## main #1074 +/- ##
==========================================
+ Coverage 61.06% 61.10% +0.03%
==========================================
Files 264 264
Lines 26221 26237 +16
==========================================
+ Hits 16013 16031 +18
+ Misses 8527 8526 -1
+ Partials 1681 1680 -1
... and 5 files with indirect coverage changes 🚀 New features to boost your workflow:
|
update boxo to ipfs/boxo#1074 and gateway-conformance tests to ipfs/gateway-conformance#252 for testing IPIP-523 changes where ?format= URL query parameter takes precedence over Accept HTTP header
update boxo to ipfs/boxo#1074 and gateway-conformance tests to ipfs/gateway-conformance#252 for testing IPIP-523 changes where ?format= URL query parameter takes precedence over Accept HTTP header
remove HTTP 400 error for conflicting ?format and Accept values. instead, ?format silently takes precedence, which is simpler and less breaking for browser clients that send Accept headers automatically.
update boxo to ipfs/boxo#1074 and gateway-conformance tests to ipfs/gateway-conformance#252 for testing IPIP-523 changes where ?format= URL query parameter takes precedence over Accept HTTP header
lidel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CI with end-to-end tests at
are green.
AFAIK this PR is a low risk change (see Compatibility section in IPIP-523)
temporary switch to ipfs/gateway-conformance#252
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Switched to gateway-conformance@v0.9, merging.
This is low risk change, we will test on gateway staging with Kubo 0.40.0-rc1.
* test: IPIP-523 format query precedence over Accept header update boxo to ipfs/boxo#1074 and gateway-conformance tests to ipfs/gateway-conformance#252 for testing IPIP-523 changes where ?format= URL query parameter takes precedence over Accept HTTP header * chore: update boxo and gateway-conformance for IPIP-523 testing - boxo@9aeb0c835899fedb4f886040a4ccf3ba09fd97d4 - gateway-conformance@c82a2a9bc79303e0f07216a80cf454ef2a1e042c * chore(ci): switch to gateway-conformance@v0.9 * chore: update boxo with IPIP-523 changes * chore: update boxo to main after ipfs/boxo#1074 merge * docs: add gateway-conformance v0.9 to changelog
this change simplifies precedence rules by making the
?format=URL query parameter always take priority over the Accept HTTP header when both are present.in practice, this is largely compatible with existing browser use cases since browsers send Accept headers with wildcards which were already treated as non-specific. prioritizing
?format=also ensures deterministic HTTP caching behavior, protecting against CDNs that commingle different response types under the same cache key.the only breaking change is for edge cases where a client sends both a specific
Acceptheader and a different?format=value. previouslyAcceptwould win, now?format=wins. this scenario is rare and arguably represents client misconfiguration. when detected, gateway returns HTTP 400 to signal the ambiguity.TODO