I really don't think this is a PHP issue. You are most likely hitting the fact that HTTP/1.1 connections default to be persistent (keep-alive) so they are sitting there waiting for the keep-alive timeout. Send a "Connection: close" header to test that theory.

I believe this is a duplicate of request #65634 — it was implemented on PHP-5.6 and master, but I elected not to backport it due to the (slight) behavioural change.

Agreed - sounds related to request #65634.
Reading your comments (and given a nod to my completely lack of understanding of the underpinnings in PHP), I wonder if this may also be a documentation "problem".

Two points:

a) The documentation http://www.php.net/manual/en/wrappers.http.php does seem misleading in that it implies that function is restricted to HTTP 1.0 GET. May I suggest a slight rewording:
"Allows access to files/resources via HTTP. By default, a HTTP 1.0 GET is used."

b) http://www.php.net/manual/en/context.http.php allows to set protocol_version 1.1, however, doesn't elaborate/warns, if that requires any special accomodation by the script programmer?

Reading your (much appreciated) feedback, I now wonder how HTTP 1.1 is implemented in the streams/HTTP contexts with respect to managing the open connection(s) and possible server connection limits? If a script makes 50 x 2 HTTP 1.1 requests against the SAME web server, each set being an fsopen() HEAD request with a new stream_context_create that (among other things) sets protocol_version 1.1, followed by another stream_context_create and copy() GET request with protocol_version 1.1 - how are the keep-alive connections handled?

If each fsopen()/copy() reuses the SAME open connection (as I had naively assumed), then there should be no "timeout" consideration - but it should save on TCP setup/breakdown times. Of course, I do (now) understand that I should send an explicit "Connction: Close" header with the final iteration of the loop, before proceeding on with a different web server.

But - after reading your comments I wonder, whether the HTTP 1.1 implementation in the HTTP contexts will simply open a NEW connection (just like HTTP 1.0 does) - but then leaves it open... never to be re-used. This would explain why eventually a connection limit implemented on the server might be reached, causing subsequent requests to have to wait for time-outs.

If the LATTER is the case, then I believe it requires appropriate mention in the documentaiton that protocol_version 1.1 must not be set, unless the script programmer manages the open connections themselves (an maybe link to relevant chapter in the documentation).

Per example - does it require that only ONE stream_context is created for that server because THAT resource actually holds the persistent HTTP 1.1 connection and that this ONE context be passed to all fsopen(), copy() etc. requests in order to actually reuse the SAME connection? In that case any unique headers (such as "if-modified-since") would have to be "modified" (rather than "created") in that existing stream_context by means of stream_context_set_option?

If THAT is the case, then the solution to #65634 actually does NOT seem appropriate to me. If the above is properly documented, then HTTP 1.1 implies KEEP-ALIVE - which probably would be the key reason why the script writer explicitly went throug all the effort to set protocol_version 1.1 in the first place. Negating that with a "Connection: Close" and forcing the script author to also specify "Connection: Keep-Alive" seems like a counter-intuitive twist. 

Rather than turning off persistent connections by default, it would seem more appropriate to document how a script author has to manage/reuse the persistent connection that HTTP 1.1 opens.