spec: add Accept-Payment negotiation#231
Conversation
Spec Preview
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3e732c27d3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - Filter challenges to those matching at least one declared range with `q>0` | ||
| - Order matching challenges by descending client `q` value | ||
| - Preserve server preference order when multiple matches have the same `q` | ||
| - Prefer the most specific matching range when multiple ranges match the same challenge |
There was a problem hiding this comment.
The selection rules let a challenge pass as long as it matches any range with q>0, which means an explicit opt-out can be overridden by a broader wildcard. For example, Accept-Payment: tempo/*;q=1, tempo/charge;q=0 would still allow tempo/charge under the current bullets, even though the client explicitly disallowed it. This breaks the stated “same weighted-preference model” behavior and can cause servers to return challenges the client said not to use; compute the effective match from the most specific range first, then drop challenges whose effective q is 0.
Useful? React with 👍 / 👎.
| Examples: | ||
|
|
||
| ~~~http | ||
| Accept-Payment: tempo/charge, tempo/session, stripe/charge;q=0.5 |
brendanjryan
force-pushed
the
brendan/accept-payment-header
branch
from
2085445 to
0a8fbe1
Compare
4 participants
Summary
Many MPP servers support multiple methods/intents, which is good for increasing coverage of compatible clients, but can result in wasted computation on the server (generating details for methods that a client may never use) as well as unclear selection criteria in clients, which today use the first supported method returned by the server
We address this by adding an
Accept-Paymentheader, which allows clients to declare which payment methods they support and their relative preference.This is modeled after the
Accept-Languageheaderhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Language