I cannot find this information anywhere, since all questions are library specific or are about forcing use of HTTP/2.
Is it possible to set (force) the HTTP version to HTTP/1.1 via headers when connecting to a server using HTTPS?
I have read that servers set the HTTP version to HTTP/2 by default when using HTTPS, but that HTTPS does not necessarily depend on HTTP/2.
I ask because I am connecting to an end server that uses HTTPS but the server only supports HTTP/1.1 (possibly connecting via an intermediary server that supports HTTP/2).
I know you can force curl to use HTTP1.1 using a flag but I am not sure if curl sets something in the headers or does something at a lower level.
--http1.1
I can access the end server successfully using curl when using the --http1.1 flag. Without the flag, the request fails.
Ideally, I want to use other solutions other than curl to connect to the end server.
Related
According to the documentation of the HTTP OPTIONS method, one can check the communication options of an entire web server, assuming the server supports such a check. My understanding is that one needs to make an HTTP request to the server to be checked with the first line of the request being OPTIONS * HTTP/1.1. How can one make such a request with a common HTTP client? I wasn't able do it with the Postman client or the Requests HTTP client library for Python. Specifically, specifying the asterisk * along with the server's location, http://<host>/*, for example, didn't work.
I am setting the proxy on windows using the below command :
set http_proxy=http://user:password#proxy.domain.com:port
set https_proxy=https://user:password#proxy.domain.com:port
How can I verify if it has been set correctly?
There is a method using packet capture. Like wireshark.
First
It can be distinguished by port number.
In general, HTTP used port 80.
However, if you use a different port for your proxy configuration, you can distinguish is as a port number.
Two
It can be distinguished by HTTP request header.
A request URL using HTTP proxy include full URI. like GET http://www.kangmj37.com HTTP/1.1
A request METHOD using HTTPS proxy using CONNECT. like CONNECT www.kangmj37.com:443 HTTP/1.1. See RFC https://www.rfc-editor.org/rfc/rfc7231#section-4.3.6
4.3.6. CONNECT
CONNECT is intended only for use in requests to a proxy.
What are common solutions getting gRPC app running when there is a requirement to run through a some sort of proxy which does not support HTTP/2 toward origin, rather towards client side.
Were you people got this kind of setup done somehow?
The setup via proxy would create a flow similar to this:
Client <--- HTTP/2 ---> Proxy <--- HTTP/1.1 ---> gRPC Server.
Currently, it's not possible -- but stay tuned: Piotr Sikora from Google is trying to get HTTP2 upstreams supported on nginx, even though things are proceeding slower than one would expect:
https://github.com/grpc/grpc.github.io/issues/230#issuecomment-306974585
https://forum.nginx.org/list.php?29 (look for Piotr)
I'm trying to reproduce an odd bug that we believe may be caused by our load balancers trying to check the status of our services, with requests using HTTP/0.9. The service is only configured to use HTTPS, so they are being sent as HTTP/0.9 over HTTPS.
I could use use telnet to send a HTTP/0.9 request, but we have to use HTTPS so that doesn't work. My usual go-to tool for this kind of thing is cURL, but it doesn't look like cURL supports sending 0.9 requests (for good reasons, I know).
What could I use to generate a HTTP/0.9 GET request over HTTPS?
You could use openssl. First establish the SSL connection:
$ openssl s_client -crlf -connect ip:port
CONNECTED
...
lots of output, certificate etc
And then send the request
GET /
[empty line]
Imagine a webbrowser that makes an HTTP request to a remote server, such as site.example.com
If the browser is then configured to use a proxy server, let's call it proxy.example.com using port 8080, in which ways are the request now different?
Obviously the request is now sent to proxy.example.com:8080, but there must surely be other changes to enable the proxy to make a request to the original url?
RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, Section 5.3.2. absolute-form:
When making a request to a proxy, other than a CONNECT or server-wide
OPTIONS request (as detailed below), a client MUST send the target
URI in absolute-form as the request-target.
absolute-form = absolute-URI
The proxy is requested to either service that request from a valid
cache, if possible, or make the same request on the client's behalf
to either the next inbound proxy server or directly to the origin
server indicated by the request-target. Requirements on such
"forwarding" of messages are defined in Section 5.7.
An example absolute-form of request-line would be:
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
So, without proxy, the connection is made to www.example.org:80:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org
With proxy it is made to proxy.example.com:8080:
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org
Where in the latter case the Host header is optional (for HTTP/1.0 clients), and must be recalculated by the proxy anyway.
The proxy simply makes the request on behalf of the original client. Hence the name "proxy", the same meaning as in legalese. The browser sends their request to the proxy, the proxy makes a request to the requested server (or not, depending on whether the proxy wants to forward this request or deny it), the server returns a response to the proxy, the proxy returns the response to the original client. There's no fundamental difference in what the server will see, except for the fact that the originating client will appear to be the proxy server. The proxy may or may not alter the request, and it may or may not cache it; meaning the server may not receive a request at all if the proxy decides to deliver a cached version instead.