I'm building a HTTP client(for embedded devices) and I was wondering,
If I receive a HTTP 3xx response, and in the location header I get a hostname different from the one I had in the request. Should I disconnect the TCP connection and reconnect to the new host, or I just need to send a new request with a new host header and keep the old TCP connection alive.
Thank you
It doesn't make sense to reuse the original TCP connection if you're being redirected elsewhere. If my webserver only hosts example.com and I redirect you to elsewhere.net, my webserver will probably not respond to a request for elsewhere.net.
Worse, this also potentially sets you up for a great man-in-the-middle attack if my server redirects you to http://bank.com and you reuse the same TCP connection when sending a request to bank.com. My server can maliciously respond to requests with Host: bank.com, which isn't something you want to happen.
You can't assume the original connection can be reused unless the redirect is to the same same host with the same protocol.
Persistent HTTP connections are a little tricky with the number of client/server combinations. You can avoid the complexity by just wasting time closing and re-establishing each connection:
If you're implementing a HTTP/1.0 client, Connection: keep-alive isn't something you have to implement. Compliant servers should just close the connection after every request if you don't negotiate that you support persistent connections.
If you're implementing a HTTP/1.1 client and don't want to persist the connection, just send Connection: close with your request and a HTTP/1.1 server should close the connection.
Related
I'm implementing HTTP over TLS proxy server (sni-proxy) that make two socket connection:
Client to ProxyServer
ProxyServer to TargetServer
and transfer data between Client and TargetServer(TargetServer detected using server_name extension in ClientHello)
The problem is that the client doesn't close the connection after the response has been received and the proxy server waits for data to transfer and uses resources when the request has been done.
What is the best practice for implementing this project?
The client behavior is perfectly normal - HTTP keep alive inside the TLS connection or maybe even a Websocket connection. Given that the proxy does transparent forwarding of the encrypted traffic it is not possible to look at the HTTP traffic in order to determine exactly when the connection can be closed. A good approach is therefore to keep the connection open as long as the resources allow this and on resource shortage close the connections which were idle (no traffic) the longest time.
Client connects to server and sends request with keep-alive header. Server response also contains keep-alive header.
Now client loses power. Is there any mechanism (like ping) in TCP or HTTP stack, which tells server, that client is not there (other than timeout)?
Now client loses power. Is there any mechanism (like ping) in TCP or HTTP stack, which tells server, that client is not there (other than timeout)?
There is TCP keep alive which is specifically designed to detect lost connectivity.
We are trying to make a secure communication between our embedded system and web server.Firstly we implement HTTP connection to in our microcontroller. I am just connecting to 80 port of my web server and send simple GET request to this port as example below :
GET /foo.php?msg=test HTTP/1.1
HOST: foo.com
My questions is,How we will turn this to HTTPS ? Which port i should connect ?
Will be any difference on structure of GET request above ? Will i have to do some encryption manually or connect to "https" link instead "http" is enuogh for secure communication.
Thanks for any information
The only difference between a HTTP request and a HTTPS request is that the first is send over a plain TCP connection while the other is send over a TLS connection, i.e.:
with HTTP you establish a TCP connection and send the request over this connection
with HTTPS you establish a TCP connection, upgrade this connection to TLS (including proper certificate validation etc!) and then send the same request as you did with HTTP over this connection.
Apart from that I recommend to either use an established library for HTTP or carefully read the standard. Although HTTP looks simply it is actually not and there are many questions here where users try to do a simply HTTP request and trip over behavior they did not expect.
For example in your case the server might send the response with chunked encoding, with content-length or simply end it with connection close. And it might wait for further requests on the same connection since HTTP/1.1 implicitly enables HTTP keep-alive. Does your code really account for all these cases?
I noted that fiddler sends "connection:close" header when the client sends a CONNECT request to initiate secure connection along with the "200 connection established" message.
CONNECT request to a forward HTTP proxy over an SSL connection?
As explained in above question, the connection should be kept-alive between the client and the proxy so that the client can subsequently sent the actual request.
Why does fiddler sends the close header? wouldn't the client close the connection because of the header instead?.
Any Connection header in the successful response to the CONNECT request does not make any sense and gets ignored. CONNECT will establish a tunnel, which only ends with the end of the TCP connection. But a Connection header would make sense with an unsuccessful CONNECT, because with close the client would need to start a new TCP connection and with keep-alive (implicit with HTTP/1.1 response) it can reuse it with another request.
Connection: Close means that the connection will be closed after the request completes. Since the request in this scenario only completes when the HTTPS connection is closed, this is exactly the behavior you want for this sort of request.
Arguably, using Connection: keep-alive on a CONNECT request is invalid, since there's no legal way for the connection to be kept-alive after the tunnel is closed.
I am reading that Keep-Alives is meant for performance - so that no connections need to be recreated but just reuse the existing ones. What if there is a traffic spike, will new connections be created?
Additionally, if I don't turn on Keep-Alive and in a high traffic environment, will it eventually running out of connections/socket port on client side? because a new connection has to be created for each http/web request.
HTTP is a stateless protocol.
In HTTP 1.0 each request meant opening a new TCP connection.
That caused performance issues (e.g. have to re-do the 3-way handshake for each GET or POST) so the Keep-Alive Header was added to maintain the connection across requests and in HTTP1.1 the default is persistent connection.
This means that the connection is reused across requests.
I am not really familiar with IIS but if there is a configuration to close the connection after each HTTP response, it will have impact on the performance.
Concerning the running out of sockets/ports on the client side, that could occur if the client fires a huge amount of requests and a new TCP connection must be opened per HTTP request.
After a while the ports will be depleted