|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
Patchesfopen-http-request (last revision 2010-12-27 12:30 UTC by hungry dot rahly at gmail dot com)Pull RequestsHistoryAllCommentsChangesGit/SVN commits
[2016-08-04 13:06 UTC] vhu at iki dot fi
[2016-08-04 13:46 UTC] nikic@php.net
-Status: Open
+Status: Closed
-Assigned To:
+Assigned To: nikic
[2016-08-04 13:46 UTC] nikic@php.net
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Tue Oct 28 20:00:01 2025 UTC |
Description: ------------ fopen fails(sometimes, as heavier system loads it will be successful, and less load fails) web requests using http/https when behind cheap routers with content filtering on. This is due to how php sends headers. how php runs. php_stream_write("GET / HTTP/1.0\r\n"); php_stream_write("Host: www.hostname.com\r\n"); php_stream_write("\r\n"); This potentially forces 3 packet sends where cheaper hardware cannot reconstruct the request entirely. Since content filters need to know the host, the hardware fails after it gets the "GET" and hangs. Changing the code to a minimum of php_stream_write("GET / HTTP/1.0\r\nHost: www.hostname.com\r\n"); php_stream_write("\r\n"); this will force the GET and the Host line to be in the same packet. Enough for cheap hardware to see it and handle appropriately. also, opening a socket and handling the http protocol manually, works fine. The attached patch, works, but would like to test more to make sure it doesn't cause any other problems. Test script: --------------- $web = fopen("http://www.google.com/", "r"); // need cheap hardware with content filtering turned on Expected result: ---------------- On cheap hardware, it will timeout and not perform the request.