RFC 9540 directory and receiver#549
Conversation
Pull Request Test Coverage Report for Build 13777715320Details
💛 - Coveralls |
nothingmuch
force-pushed
the
rfc-9540-directory-and-receiver
branch
from
009604c to
eca7fe4
Compare
|
gotta add the ACCEPT header first |
nothingmuch
force-pushed
the
rfc-9540-directory-and-receiver
branch
from
eca7fe4 to
3a09e8e
Compare
| pub fn ohttp_gateway_url(&self) -> Url { | ||
| let url = self.directory_url(); | ||
| url.join("/.well-known/ohttp-gateway").expect("invalid URL") | ||
| } |
There was a problem hiding this comment.
I think it may make more sense to have our extract_req fns themselves url.join("/.well-known/ohttp-gateway").expect("invalid URL") since the path is the same for all functions assuming RFC 9540 compliance. That way the end user only needs to pass the directory origin and not the complete gateway url.
I suppose this would make it impossible to use our crate with non-RFC 9540-compliant directories, but I think that's our intended behavior.
There was a problem hiding this comment.
This is not actually relevant, as it is the relay which appends that path
Only the key bootstrapping GET request explicitly specifies the RFC 9540 path, which for now is optional since the old /ohttp-keys route is still supported, that functionality accepts the payjoin directory base URI as before.
The reason this method is provided is for the integration tests which bypass the relay.
nothingmuch
changed the title
The gateway is available via POST on /.well-known/ohttp-gateway OHTTP key configuration is available via GET on the same path. In this case the `Accept: application/ohttp-keys` is not required or even checked.
This change utilizes the new RFC 9540 behavior in the directory for fetching ohttp keys, and exercises this as well as OHTTP gateway functionality in the tests which bypass the ohttp-relay.
nothingmuch
force-pushed
the
rfc-9540-directory-and-receiver
branch
from
3a09e8e to
09ffcfa
Compare
| let proxy = Proxy::all(ohttp_relay.into_url()?.as_str())?; | ||
| let client = Client::builder().proxy(proxy).build()?; | ||
| let res = client.get(ohttp_keys_url).send().await?; | ||
| let res = client.get(ohttp_keys_url).header(ACCEPT, "application/ohttp-keys").send().await?; |
There was a problem hiding this comment.
You mention in the commit messages that this isn't checked anywhere in the directory. Is there a plan to require that? Seems to not make a huge difference.
There was a problem hiding this comment.
no, it seems needlessly pedantic to me, but i thought it was worth mentioning in case anyone disagrees
|
Hmm, I mischaracterized this PR. The directory side is backwards compatible, since it will handle older requests too. However, the bootstrapping code for the client depends on the new functionality, from the relay. I think I originally intended to split this PR into two parts, so we could release the directory first and and only then merge a separate PR to the receiver, but I'm not 100% sure and either way I neglected to do that, sorry. |
With this change, the payjoin directory's RFC 9540 compatible OHTTP gateway additionally opts in to receiving OHTTP requests from arbitrary relays. See payjoin/ohttp-relay#58. Depends on - #549 - #572
3 participants
This is a backwards compatible change to support RFC 9540.
The directory accepts requests at
/.well-known/ohttp-gateway. The receiver also fetches OHTTP keys from the new RFC 9540 endpoint, instead of/ohttp-keys.Unblocks payjoin/ohttp-relay#47.