You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
http2 not work when proxies apply to the AsyncClient #873
I'm wondering if the reason you don't get HTTP/2 back is due to verify=False. AFAIK HTTPS is required by us for HTTP/2 to work (we don't support Upgrade: h2c yet, see #503).
In general, what really helps is to be able to reproduce against a 100% local setup. Can you clarify what your localhost proxy is?
Eg I tried to spin up a local HTTP/2 + HTTPS setup using trustme-cli, hypercorn and mitmproxy. I'm running into certificate issues between the server and the proxy, but here's what I've got:
<Response [502 Bad Gateway]> HTTP/1.1<Response [502 Bad Gateway]> HTTP/1.1<html> <head> <title>502 Bad Gateway</title> </head> <body> <h1>502 Bad Gateway</h1> <p>Certificate verification error for localhost: unable to get local issuer certificate (errno: 20, depth: 0)</p> </body> </html>
mitmproxy output:
127.0.0.1:61974: clientconnect127.0.0.1:61974: CONNECT localhost:8000 << Certificate verification error for localhost: unable to get local issuer certificate (errno: 20, depth: 0)127.0.0.1:61974: clientdisconnect
First the client sends an HTTP/1.1 request requesting to the server an upgrade to HTTP/2 by providing some headers like: Connection: Upgrade, HTT2Settings, Upgrade: h2c, HTTP2Settings: ... . If the server can speak HTTP/2 then it answers with a response status 101 (Switching Protocol), and then the actual response to the request in HTTP/2 protocol.
Second is known as "with prior knowledge". The client does not send a first HTTP/1.1 request but directly send the request in HTTP/2 format (with frames...) assuming "with prior knowledge" that the server understands the HTTP/2 protocol. All of this without TLS.
Implementing the second option "with prior knowledge" would be very useful to query HTTP API without having to generate certificates (even self-signed).
I'm wondering if the reason you don't get HTTP/2 back is due to verify=False. AFAIK HTTPS is required by us for HTTP/2 to work (we don't support Upgrade: h2c yet, see #503).
@florimondmanca I can verify that setting verify to anything, not just False, seems to break the HTTP/2 support. See example:
@gnubibored No, there doesn’t seem to be an obvious solution yet; looks like something is simply not working on our side.
There is work being done in the HTTPCore repo to improve our proxy implementation and properly support HTTPS there, hopefully it will help us resolve this.
the issue is this wasnt happening when 4 months ago i was using httpx, so im gonna try using a previous release for see in what change works and in what no
Someone found something about this? I been trying different versions but im not able to reproduce the issue, maybe i was wrong, in the ones i tested i get errors with ssl or i get http/1 when using proxy
Activity
florimondmanca commentedon Mar 24, 2020
Hi @houoop,
I went ahead and fixed the code formatting.
I'm wondering if the reason you don't get HTTP/2 back is due to
verify=False. AFAIK HTTPS is required by us for HTTP/2 to work (we don't supportUpgrade: h2cyet, see #503).In general, what really helps is to be able to reproduce against a 100% local setup. Can you clarify what your
localhostproxy is?Eg I tried to spin up a local HTTP/2 + HTTPS setup using trustme-cli, hypercorn and mitmproxy. I'm running into certificate issues between the server and the proxy, but here's what I've got:
Click to expand
Dependencies:Generate
localhostcertificates:$ trustme-cli $ cat server.key server.pem > cert.pemASGI app:
Start hypercorn:
Start the proxy:
$ mitmdump --cert "*=cert.pem"HTTPX script:
HTTPX output:
mitmproxy output:
laurentvaills commentedon Apr 2, 2020
HTTP/2 cleartext can be achieved in 2 ways:
First the client sends an HTTP/1.1 request requesting to the server an upgrade to HTTP/2 by providing some headers like:
Connection: Upgrade, HTT2Settings,Upgrade: h2c,HTTP2Settings: .... If the server can speak HTTP/2 then it answers with a response status 101 (Switching Protocol), and then the actual response to the request in HTTP/2 protocol.Second is known as "with prior knowledge". The client does not send a first HTTP/1.1 request but directly send the request in HTTP/2 format (with frames...) assuming "with prior knowledge" that the server understands the HTTP/2 protocol. All of this without TLS.
Implementing the second option "with prior knowledge" would be very useful to query HTTP API without having to generate certificates (even self-signed).
valiant1x commentedon Apr 10, 2020
@florimondmanca I can verify that setting
verifyto anything, not justFalse, seems to break the HTTP/2 support. See example:Is there a better way to specify SSL cipher suites that does not break HTTP/2 support?
qwerty32123 commentedon Apr 12, 2020
im having these exact problem, using verify and http2 and proxy #905
is there any solution?
florimondmanca commentedon Apr 13, 2020
@gnubibored No, there doesn’t seem to be an obvious solution yet; looks like something is simply not working on our side.
There is work being done in the HTTPCore repo to improve our proxy implementation and properly support HTTPS there, hopefully it will help us resolve this.
qwerty32123 commentedon Apr 13, 2020
the issue is this wasnt happening when 4 months ago i was using httpx, so im gonna try using a previous release for see in what change works and in what no
florimondmanca commentedon Apr 13, 2020
Thanks, would be useful to pinpoint at which release this started occurring, indeed. :-)
qwerty32123 commentedon Apr 19, 2020
Someone found something about this? I been trying different versions but im not able to reproduce the issue, maybe i was wrong, in the ones i tested i get errors with ssl or i get http/1 when using proxy
yeraydiazdiaz commentedon May 4, 2020
I just merged a change in HTTPCore dealing with this issue so this should be resolved from httpx 0.13.
houoop commentedon May 4, 2020
@yeraydiazdiaz Thanks, I'm looking forward to the latest release.
valiant1x commentedon May 10, 2020
I can confirm the issue is resolved in 0.13.0.dev1 release. HTTP/2 is preserved when specifying a custom
verifySSL context.