This issue is a result of mix-up between Proxy SG's Client & Server socket persistence in combination with the Origin Content Server (www.hub.com) responses.
What's happening behind the scenes: 1. The client for the very first time issues a GET for https://www.hub.com/ using HTTP 1.1. This is actually two requests, first CONNECT request, followed by the actual GET request.
Proxy SG treats this as a Client side persistable request and initiates a secure socket communication with the Origin Content Server (i.e. www.hub.com in this case). This secure socket communication is initiated owing to the CONNECT request. The GET request causes Proxy SG to issue a GET to the OCS. The OCS responds with a 200 OK along with the packet data for the file requested, marked with HTTP header Connection: close. This close connection header causes Proxy SG to not enforce the Server side persistence. Hence it closes the secure socket on the server side. It sends the 200 OK response along with the file's packet data and keeps the client side socket still 'alive' owing to client side persistence.
2. Now the client browser issues the same request (GET) on same socket again with If-Modified-Since header. This time it is a single request, GET.
Proxy SG again treats this as a Client side persistable request and tries to initiate a secure socket communication. However it fails to initiate secure socket communication as it has lost all context. Remember ProxySG needs a CONNECT to correctly initiate secure socket communication with the Origin Content Server. The client browser would not send CONNECT again owing to the fact that it is sending the request on the same socket.
The following policy should address the problem by preserving the web browser's connection persistency according to the origin server's persistency.