Comments (7)
We talked about hyper
having a layer which acts as a drop-in replacement for httplib
. That would be easiest to transition with.
If I recall the scope for hyper
right now is to only support HTTP/2.0+? If there are plans for having HTTP/1.0+ support, then I'd be happy to drop httplib
altogether and use whatever native interface hyper
has.
We'll probably need an easy way to differentiate between an HTTP/2.0+ vs HTTP/1.1- server, ideally as early in the connection process as possible. Maybe some utility helper for this could live inside hyper
?
Also, I assume if we're moving forward, then we're going to vendor this into urllib3.
from hyper.
The drop-in replacement layer is on the table, and is the interface I would expect urllib3
to use.
You're right about the scope stuff. At this time, writing a complaint HTTP/1.1 parser is a little bit too much work, and I'll introduce some alarming bugs into urllib3 that I doubt you want. I'm open to considering it, but it's very long term.
What do you have in mind when it comes to differentiating? The obvious concern is about connection pooling, yeah?
As for vendoring: that was what I expected. =) For all the reasons Requests vendors urllib3
, urllib3
would want to vendor hyper
.
from hyper.
The drop-in replacement layer is on the table, and is the interface I would expect urllib3 to use.
Would be neat if this compatibility layer automagically chose whether to use hyper or httplib, depending on the server type. That would truly be the minimal amount of work needed for urllib3 to migrate.
You're right about the scope stuff. At this time, writing a complaint HTTP/1.1 parser is a little bit too much work, and I'll introduce some alarming bugs into urllib3 that I doubt you want. I'm open to considering it, but it's very long term.
I'm willing to take the risk if you decide to delve into it. :)
What do you have in mind when it comes to differentiating? The obvious concern is about connection pooling, yeah?
I mean more if it was up to urllib3 to decide whether to use hyper or httplib for any given connection/request, it'd be nice if there were some helpers which streamlined that decision.
from hyper.
Ah, yes, that's the compatibility layer plan. It'll use TLS next-protocol-negotiation to make the decision. The biggest difficulty here is trying to do this cleanly while maintaining http.client
's "connect as late as possible" policy.
from hyper.
Yea, not sure how much work/complexity this kind of abstraction would involve. If you'd like a more incremental approach, I'd be open to having a separate (or configurable) non-default PoolManager
dedicated for HTTP/2.0+ to start.
from hyper.
I don't think it'll be too bad. Maybe.
from hyper.
So the consensus here is that the obvious block is #3.
from hyper.
Related Issues (20)
- Ping does not work correctly HOT 3
- Edit on github link on RTD broken.
- Transfer of maintenance HOT 3
- HTTP20Adapter sends extra headers ?? HOT 20
- How to control ssl context in a HTTP20Adapter HOT 1
- hyper.contrib.HTTP20Adapter with requests.session not working on python 2.7
- Upgrade from HTTP/1.1. to HTTP2 not working HOT 2
- Could you please make MAX_CHUNK configurable? HOT 1
- Upgrade to the latest h2 HOT 2
- How resolve DNS to a specific IP?
- HTTP11Connection does not use http/1.1 protocol HOT 1
- hyper hangs while POSTing to Apple APNS servers HOT 2
- Forcing Cleartext HTTP2 Without Upgrade Mechanism HOT 3
- How can I add query parameters when using class HTTP20Connection?
- Python deprecation warnings: collections, imp, logging.warn
- basestring erroneously ignores unicode in Python2.7
- Client certificates?
- Retain connection in HTTP/2 using hyper to avoid authentication for every request
- HTTP20Connection.request has no mechanism to send duplicate headers HOT 3
- The orders of sending packages in Debug mode and Run mode are different.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hyper.