there are a bunch of tests which have expectations on the headers sent by the client, could you also update them?

Sure, forgot to update them, good guy Travis. Updated all failing tests and added a NEWS entry.

Isn't it more about server configurations? Say servers setting keep-alive on by default together with some too high timeout. In PHP there's a stream context that can be passed with the desired connection control header, thus signaling an app doesn't support persistent connections.

Thanks.

As PHP doesn't support keep-alive by default, there's no reason not to send that header here if not specified otherwise.

It may be a server issue as servers should probably not use keep-alive connections for HTTP/1.0 requests, but it doesn't have anything to do with a too high timeout, any timeout will delay PHP's return of file_get_contents.

Nope, it is about timeout on server as well, fe see KeepAliveTimeout. Or more alike about server misconfiguration, which is an error case anyway. Most of the servers today will respond with HTTP/1.1 to a HTTP/1.0 request. A properly configured server will respond with "Connection: close" and close the connection, or actually any other usable scenario. There is probably a little sense to fix someones misconfiguration. Could you please point to an example server to reproduce the actual subject?

Thanks.

@weltling this problem is reported by several users on stackoverflow (for years), see

http://stackoverflow.com/questions/3485843/file-get-contents-with-context-to-use-http-1-1-significantly-slow-download-spe

http://stackoverflow.com/questions/3629504/php-file-get-contents-very-slow-when-using-full-url

http://stackoverflow.com/questions/18187419/get-file-contents-when-connection-is-keep-alive

http://moffe42.blogspot.de/2010/10/filegetcontents-acting-very-slow.html

@kelunik ok, that's the exact case - the server chooses to not to turn off keepalive. Actually a stream context were appropriate solution, also looking at the links by @staabm. Sending the connection: close always is probably doable as well, because file_get_contents will close at the end, so can't profit from keepalive anyway.

Though next question - how do one clear the connection header when it's explicitly not wished? As this will affect any possible functions like fopen().

Thanks

When do you want to clear it? You can always override it by setting a stream context. If HTTP/1.1 is in use Connection: close would already be sent automatically. This patch just gets the additional HTTP/1.0 → HTTP/1.1 with keep-alive case right.

@kelunik clearing in the meaning that no Connection header is being sent. Overriding to keep-alive or anything alse does not really make sense for file_get_contents() - it will always close the stream at the end. And the HTTP wrapper doesn't support writing. But clearing that header might or might be not needed in some situations, just don't see how to do it in this patch. Hence the question.

Btw setting stream context to use HTTP/1.1 currently doesn't automatically send the Connection header.

Cheers.

Overriding to keep-alive or anything alse does not really make sense for file_get_contents() - it will always close the stream at the end

wouldnt it make sense to at least keep the connection open until the current http request was completed?
(so one could benefit from the keep alive when doing N*file_get_contents-requests while one php-request-response cycle)

$o1 = file_get_contents('http://www.google.com/abc');
// re-uses the http connection because within the same request
$o2 = file_get_contents('http://www.google.com/def'); 

Setting stream context to HTTP/1.1 does send automatically Connection: close: https://github.com/php/php-src/pull/1490/files#diff-e0dff85f21e939e4e2a778bddb8a72d7L582
Actually, it has to send it, because IIRC, HTTP/1.1 is keep-alive by default.

It's not possible not to send a Connection header at all with this patch, however this has not been possible before when using HTTP/1.1 as well.

It would probably be the best solution to just close the connection after Content-Length bytes have been read instead of sending Connection: close always, like browsers do it.

@kelunik I read in the past about some issues Firefox has because of http 1.1 and Content-Length etc.

http://daniel.haxx.se/blog/2015/02/12/tightening-firefoxs-http-framing-again/
TL;DR just reading content-length bytes will not always work

@staabm HTTP/1.0 doesn't support chunked encoding, but there may be other issues with servers that do not send Content-Length headers, right.

@kelunik indeed, it does send Connection: close starting with 5.6 for HTTP/1.1, checked wrong PHP version previously. Ok, so then all my questions are cleared out.

Thanks.

@staabm, yeah, parsing Content-Length might be a lot of fun in some case, not even talking about chunked transfer-encoding :)

Thanks.

Fine, so it's ready to be merged now?

Comment on behalf of bwoebi at php.net:

Merged via 4b1dff6