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
Proposal v4.0 b1 (HTTP/2+3, OS Trust Store, Custom DNS, OCSP, ...) #1531
base: master
Are you sure you want to change the base?
Conversation
46f030c
to
16ccc1b
Compare
16ccc1b
to
741017e
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
faf9aef
to
c12f000
Compare
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #1531 +/- ##
==========================================
- Coverage 97.28% 94.31% -2.98%
==========================================
Files 67 117 +50
Lines 4235 8296 +4061
==========================================
+ Hits 4120 7824 +3704
- Misses 115 472 +357 ☔ View full report in Codecov by Sentry. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as resolved.
This comment was marked as resolved.
52653e4
to
247b382
Compare
0b4eebb
to
7dd1152
Compare
So far, I identified this: |
We can add the following arguments and document them:
|
7dd1152
to
7257a74
Compare
I've added and documented it.
Ideally, the connection information (TLS, Cipher, Peer/Issuer Certificate, and OCSP) should be in the request metadata and with a lexer instruction. |
7257a74
to
4c246e4
Compare
4c246e4
to
f034379
Compare
Damn this looks so tantalizing. I'd love for this to get packaged as a tryout / beta. Something installable via e.g. |
f034379
to
df42bba
Compare
So, I did some additional testing on my end and found nothing. This branch now have 0 warning. For a side note, Niquests just landed Happy Eyeballs feature in the last version, if this is of any interest to you, let me know. and that commit cce24fe has nothing to do with Niquests or HTTPie really, you must have encountered this situation where a single MacOS test was flaky, this circumvent the random CI failures. |
I applied a minor patch to improve how the QuicCapabilityCache blend into HTTPie internals (the path is now generated within env::config and propagated appropriately). Tests added to ensure no regression happen in between. |
0ffa142
to
6e43380
Compare
6e43380
to
b010eff
Compare
@dwt You can help by proof reading the modified documentation and look if I missed something regarding this PR in it: https://github.com/Ousret/httpie/blob/feature-tryout-niquests/docs/README.md Other than that, I think the testing part is pretty much covered. Finally I have added a test case for the following scenario: "A peer was H3 compatible but not anymore and expect a error msg that explain why you just got timeout and how to remedy". |
…threaded warnings
…ersions published
…t_update_warnings.py
fb54d2b
to
b4f80e6
Compare
b4f80e6
to
eb93eab
Compare
I've had a look at the docs and so far everything seems fine. However I noticed the absence of a |
You cannot force HTTP/2 using Niquests. It is negotiated via ALPN/TLS. So if the server misinterpret ALPN or discard it, HTTP/2 won't come. And yes, RFC allows it, see https://datatracker.ietf.org/doc/html/rfc9113#name-starting-http-2-with-prior- but I decided to follow the simplest path forward (ALPN/TLS), as browsers do (https://stackoverflow.com/questions/34076231/why-do-browser-implementations-of-http-2-require-tls). I might reconsider it in the future, but the use cases are rare. |
I may be missing something here, but does that imply that the client has no way to force http1 2 or 3 according to its wishes? When setting up server support for these protocols, I would like to have the ability to force all of these protocols for debugging purposes? |
There's many possibilities, the only missing piece is "force http2" or "disable http1".
Hope that clarify. |
Just updated the docs to include previous comment about protocol combo and the availability of HTTP/3 or not. Finally, we had to downgrade macos-14 (macos-latest) to macos-13 because it's relatively new and some dependencies like brotlicffi aren't ready for it. |
Hello @Ousret , nice work here ... is there an ETA on when to expect this release to become available? Thank you |
No precise ETA. We are waiting upon the owner approval. |
This PR showcases how HTTPie could evolve outside of Requests.
Niquests is supposed to be a (mostly) compatible fork of Requests.
Try this preview:
$ pip install "git+https://github.com/Ousret/HTTPie.git@feature-tryout-niquests" -U
Here are the biggest pros of this:
Obviously, cons:
Complete list of changes in the fork: https://github.com/jawah/niquests/blob/main/HISTORY.md
http
#15274.0.0.b1 (unreleased)
User-Agent
, andAccept-Encoding
headers. (#1502)--resolver
. DNS over HTTPS, DNS over TLS, DNS over QUIC, and DNS over UDP are accepted. (#99) (#1531)--interface
. (#1422) (#1531)--local-port
. (#1456) (#1531)-6
or-4
. (#94) (#1531)requests_toolbelt
in favor of directly includingMultipartEncoder
into HTTPie due to its direct dependency to requests. (#1531)multidict
in favor of implementing an internal one due to often missing pre-built wheels. (#1522) (#1531)This fix has the particularity to consider 0 byte long stdin buffer as absent stdin. Empty stdin buffer will be ignored.
-1
to retrieve packets as they arrive. (#1531)From the HTTPie user perspective, they are "prettified" on the output by default. e.g. "x-hello-world" is displayed as "X-Hello-World".
The plugins are expected to work without any changes. The only caveat would be that certain plugin explicitly require
requests
.Future contributions may be made in order to relax the constraints where applicable.