CONNECT, Upgrade, and HTTP/2 bi-directional streaming.

Open
  • Is something wrong?
#436 9 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
python
Domain
api, networking

Research direction

The issue proposes a low-level Transport API covering CONNECT, HTTP Upgrade, and HTTP/2 bi-directional streaming, but names no files, tests, or entry points. Start by reviewing the existing transport API and the related WebSockets issue (#304), then identify use cases and resolve how accepted and rejected CONNECT responses should expose different stream interfaces. Done means a settled API design with an implementation and tests for the described protocols.

Written by the indexing model from the issue text.

Description

Originally opened by @tomchristie on 2020-08-08 11:29:35 in encode/httpx

At some point we ought to consider a low-level Transport API for exposing the functionality offered by the HTTP CONNECT method, the HTTP Upgrade header, and HTTP/2's bi-directional streaming. (Eg. as used by gRPC)

All there of these essentially offer the same thing - a means of obtaining a raw connection over HTTP.
The connection itself might either be the actual TCP connection (HTTP/1.1) or just a single stream (HTTP/2), but this should be ~transparent to the user, except for the fact that we might want to expose some functionality such as "now start TLS on this connection" that is only appropriate in the HTTP/1.1 case.

One thing that's potentially a bit fiddly about the API, is that the connect request can either be accepted or rejected, and we've got different kinds of stream interfaces we want to expose in each case. (Ie if it's rejected, then we want to return a regular byte stream representing the HTTP response, otherwise we want to return some kind of Connection interface.)

This issue is related to WebSockets support (which uses the HTTP Upgrade mechanism), but I think we want to provide a dedicated API for that use case, rather than building our websockets support on top of a low level connect mechanism.

Would be useful to hear from any folks with use cases in this area.

Dominant language
Python
Stars
1.6k
Forks
103
Avg merge
1d 19h
Merged PRs (30d)
25

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pydantic/httpx2

All issues in pydantic/httpx2

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.