This question applies only for HTTPS requests.

Lets divide the problem in 3 areas.

1. The origin. This is the user sending an HTTPS request.
2. The proxy. This will handle the request, forward it to the remote and vice-versa.
3. The remote. This is the server where the request is supposed to arrive.

When you make an HTTPS request through a proxy, this is what happens:

1. Origin sends with HTTP (this is not encrypted):

   CONNECT remote.url:443 HTTP/1.1 ...

2. Proxy replies:

   HTTP/1.1 200 Connection established

3. Origin sends the request to the proxy, totally encrypted:

   Cﾦￔi ﾧJ￁,ﾀﾯH;ﾎUﾬ*￿ﾈﾷ#cR￾{gﾘ ﾷ�ￄﾞWuﾠY<u#1ﾅ￳#j￴iￗHﾱￗk...

4. Proxy takes it as it is, and it forwards it to remote:

   Cﾦￔi ﾧJ￁,ﾀﾯH;ﾎUﾬ*￿ﾈﾷ#cR￾{gﾘ ﾷ�ￄﾞWuﾠY<u#1ﾅ￳#j￴iￗHﾱￗk...

5. Remote replies, it is also totally encrypted:

   cR￾{gﾘ ﾷ�ￄﾞWuﾠY<u#1...

6. Proxy passes this to the origin:

   cR￾{gﾘ ﾷ�ￄﾞWuﾠY<u#1...

7. Origin knows how to decrypt this and it is happy to receive the response.

The question is, how does the proxy knows that the response is terminated?. The proxy is just reading streams, and cannot know the end of it. Moreover, it cannot read HTTP headers to know the length because they are encrypted.

I am facing this issue in Java and I don't know how to deal with that.

CodePudding user response：

The encrypted communication goes from the client to the server, and the proxy is unaware. However the byte stream traverses two TCP connections: The one from the client to the proxy, and the one from the proxy to the server.

If either one of them gets terminated the proxy can close the other. Termination is indicated by the network stack, and the proxy just forwards that message into the other connection.

So if the client hangs up, the proxy would notice a hangup on client side and terminate it's connection to the server. On the server side a termination on client side is noticed. And if the server hangs up, the same happens in the other direction.

CodePudding user response：

Http connection is nothing but network connection between two sockets. To end an HTTP connection socket.close() needs to be called. Normal HTTP connections (not pipelined) use this method.

There are multiple scenarios how it is done. Let's take a simple example to emulate your scenario.

• Client calls proxy server. That is a HTTP connection between client & proxy, Let's call it connection A.
• Proxy calls destination using new separate HTTP connection. Let's call it connection B.
• Destination sends encrypted data to proxy via connection A.
• Proxy forwards the data packet to client via connection B.
• Client reads the data & decrypts it. It gets to know response payload size from Content-Length header.
• Once client is done reading that many bytes, it decides to call socket.close() on Connection A.
• Proxy detects connection A got closed. So it doesn't need to maintain connection B to destination & closes it.

So both HTTP connections got terminated. And it didn't need proxy to read encrypted data.