Skip to content
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

Alternative HTTP services #1138

Open
quasicomputational opened this issue Jan 6, 2021 · 1 comment
Open

Alternative HTTP services #1138

quasicomputational opened this issue Jan 6, 2021 · 1 comment
Labels
B-rfc Blocked: Request for comments. More discussion would help move this along.

Comments

@quasicomputational
Copy link

quasicomputational commented Jan 6, 2021

Alternative services (RFC 7838) are a way of separating the a request's logical origin from its network location.

That is, if you know that the origin foo.example has an alternative HTTP/2 service running on bar.example, in order to fetch the URL https://foo.example/, you could connect to bar.example on TCP port 443, validate that the server's certificate is valid for foo.example, and then issue the request.

Alternative services can be discovered (today via the Alt-Svc header or the ALTSVC frame, and eventually over DNS), or they can be known prior to making any requests (e.g., hardcoding that quic.example supports HTTP/3 on UDP port 443 to save round-trips and actually benefit from 0 RTT connection establishment).

reqwest's API is compatible with discovered alternative services - presumably they'd be handled internally and transparently, and the consuming code doesn't even have to notice. That's not implemented by reqwest yet - but, if there was a prior-knowledge API, consuming code that cares could perform discovery itself.

However, reqwest does not allow for prior-knowledge alternative services: the API takes the request's URL and then looks up the hostname from there.

This problem - separating the request URL and the location to connect and sent the request to - very much resembles #39 (connecting to Unix sockets) and #561 (bypassing DNS altogether). I think the API for prior-knowledge alternative services should be able to cover both. That means that it should be possible to mark a prior-knowledge alternative service as the only way to connect, rather than merely being an option. (There's also some fiddliness with Unix sockets, HTTP/1.1 vs HTTP/2, and TLS - for a https URL, it should be possible to have the Unix socket speak TLS, direct HTTP/1.1, or direct HTTP/1.1, but that information can be provided as part of the prior knowledge.)

@seanmonstar
Copy link
Owner

I don't have much of an idea in my head what this would look like, but I agree that it'd be useful and fits with reqwest's goal. I'm happy to read proposals on how to add this.

@seanmonstar seanmonstar added the B-rfc Blocked: Request for comments. More discussion would help move this along. label Jan 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-rfc Blocked: Request for comments. More discussion would help move this along.
Projects
None yet
Development

No branches or pull requests

2 participants