I need to send requests with http3 support for parsing the site (only http/3 requests are accepted). I found one single python module "http3", but now it is not supported by the developer and there is no possibility to set "proxies" parameter in the request.
Is it possible to provide support for http/3 version of requests with "requests" library? Or is there a similar module or solution?
Related
I have a Gateway API that is built with Golang. We use the "net/http" library documented here https://pkg.go.dev/net/http#example-ListenAndServeTLS. This service has HTTPS connection set up. The connections to my ELB’s use HTTPS because I use TLS termination. So this one Gateway API has the ssl cert. But then passes the connection to a regular HTTP connection to the other instances.
In short, the Gateway API has HTTPs support, but the services connected to my Gateway API uses HTTP.
When I check my UI services, It shows that we are using HTTP 1.1 still. However from Golang's documentation the package "net/http" should provide HTTP 2.0 support automatically.
Do I need to upgrade my internal services to use HTTPs instead of HTTP in order to use http 2.0?
Sorry If this post comes off as ignorant or rude. I really appreciate anyone taking there time to read this, and am willing to provide any more information that Is needed.
http2 include h2(TLS) h2c(no TLS), net/http use h2 default when ListenAndServeTLS.
if you use http, net/http not use h2c, but http1.1 currently no browser supports HTTP/2 unencrypted
becase net/http don't support h2c default, if you want use h2c(non-TLS version of HTTP/2):
https://pkg.go.dev/golang.org/x/net#v0.0.0-20220421235706-1d1ef9303861/http2/h2c
I have two set of users using okhttp/2.7.0 and okhttp/3.12.0. I want to enable http2 in nginx only for those users who are using okhttp/3.12.0. The client ensures to send their identifier. Is there a way to use this information and enable http2 only for those users.
Note: Multiple ports is not an option for me.
My nginx and OS version
nginx version: nginx/1.14.2
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.4)
built with OpenSSL 1.0.2h 3 May 2016
TLS SNI support enabled
My nginx conf goes like this
server {
listen 443 ssl http2;
...
This is not really possible. The client is only sent as part of a HTTP message, which is only sent after the version of HTTP to use is decided, obviously. The initially message to create the connection, and set up the SSL/TLS parameters won’t have the client (which is usually where the HTTP version is decided using the ALPN extension to TLS).
There are however other ways this might be possible, including:
Depending on the capabilities of the client. I’m not familiar with okhttp but from a quick Google it seems ALPN support was only added in v3, so you could disable the older NPN on your server and then, if that is correct, then in theory the older client will not be able to negotiate HTTP/2 so will fallback to HTTP/1.1. Unfortunately there appears to be no Nginx config option for that so you’d need to build a special version of OpenSSL without NPN support and then compile Nginx against that. Probably more hassle than it’s worth.
Use Apache instead of Nginx as it never supported NPN
Using Multiple IPs and somehow directing each version to a separate IP. Though I suspect as you cannot use separate ports you probably cannot do this either.
All in all it’s a bit of hack to be honest and so is not something that I would suggest you pursue. What you have not explained however is why you want to use HTTP/2 for one set of clients but not the other. Maybe there’s a better way to achieve what you want if you explain that.
Is there any way to identify if a client accept HTTP/2 in asp.net 4.6+? The idea is to be able to send css/js in multiple files instead of bundles?
Request.Params["SERVER_PROTOCOL"] is always saying HTTP/1.1 even though Edge developer tools says HTTP/2
I try understand how http work's and can't understand on which level http protocol implemented, it's OS level, or it's depend from where I need use it protocol? For example if I want use it on C I must implement it on C language as library and only then use it?
Http runs on top of tcp - and tcp is implemented in the network stack of your OS.
Http protocol is used between a client and a server. What a client sends is what a server receives, and vice-versa. Http was designed for the server to simply sit and wait for requests (possibly including data), and then respond (possibly including data).
All web servers implement the server side of http. In terms of applications (let's use the term "application" to mean "client", although some might say the server is an application), the client side of http protocol will, I suppose, most commonly be implemented in an application like a browser, but also command-line applications like curl and wget implement an http client. For languages such as Python there is a http server implementation in the standard library, or there are libraries such as requests which handle the client side of http so the python author just worries about the higher-level problem of which http requests to make.
So the answer is, http is not implemented in the OS, it is implemented in applications - some client-side, some server-side.
For your C application you will either have to implement http yourself (doesn't sound like fun to me but would be a good way of understanding http implementation, I suppose) or (much less stress and much more likely to have predictable correctish behaviour) use a library if you can find one.
This is one of the Node http events. Did the obvious Google Searches, didn't find much. What is it exactly?
HTTP Upgrade is used to indicate a preference or requirement to switch to a different version of HTTP or to another protocol, if possible:
The Upgrade general-header allows the client to specify what
additional communication protocols it supports and would like to use
if the server finds it appropriate to switch protocols. The server
MUST use the Upgrade header field within a 101 (Switching Protocols)
response to indicate which protocol(s) are being switched.
Upgrade = "Upgrade" ":" 1#product
For example,
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The Upgrade header field is intended to provide a simple mechanism
for transition from HTTP/1.1 to some other, incompatible protocol.
According to the IANA register, there are only 3 registered mentions of it (including one in the HTTP specification itself).
The other two are for:
Upgrading to TLS Within HTTP/1.1 (almost never used, not to be confused with HTTP over TLS, which defines HTTPS as widely used). This upgrade allows for a similar mechanism to STARTTLS in other protocols (e.g. LDAP, SMTP, ...) so as to be able to switch to TLS on the same port as the plain connection, after exchanging some of the application protocol messages, as opposed to having the entire HTTP exchange on top of SSL/TLS without it needing to know it's on top of TLS (the way HTTPS works).
Upgrading to WebSockets (still a draft).