PHP File Serving Script: Unreliable Downloads? - php

This post started as a question on ServerFault ( https://serverfault.com/questions/131156/user-receiving-partial-downloads ) but I determined that our php script was the culprit. So I'm issuing an updated question here about what I believe is the actual issue.
I am using a php script to verify permissions and then serve up a file for users of my website to download. Most of the time, this works, but recently one user has been seeing problems with larger downloads. He is only getting ~80% of downloads for files that are > 100MB in size. Also, all downloads from this script fail to report a filesize. Further, tests revealed that the same user COULD reliably download each of the failed files if given a direct link (at which point the filesize is reported).
Here's the relevant snippet of code that we are using to serve the file:
header("Content-type:$contenttype");
$len = filesize($filename);
header("Content-Length: $len");
header("Content-Disposition: attachment; filename=".$title.".".$ext);
readfile($filename);
Note that $contenttype, $filename, $title, and $ext are all set correctly before we get here. These have been triple-checked. None of them are the problem. Also, $len does provide the correct filesize.
While researching this issue, I came across this post: Content-Length header always zero
It seems that I am encountering the same issue. When I use the script, I get chunked encoding on the file and no size is set for content-length. I'm hypothesizing that something is going wrong on the large downloads, leading him to get a zero-length chunk before the end of the file.
Here's what the headers look like for a direct request:
http://www.grinderschool.com/videos/zfff5061b65ae00e8b21/KillsAids021.wmv
GET /videos/zfff5061b65ae00e8b21/KillsAids021.wmv HTTP/1.1
Host: www.grinderschool.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.grinderschool.com/phpBB3/viewtopic.php?f=14&p=29468
Cookie: style_cookie=printonly; phpbb3_7c544_u=2; phpbb3_7c544_k=44b832912e5f887d; phpbb3_7c544_sid=e8852df42e08cc1b2250300c2897f78f; __utma=174624884.2719561324781918700.1251850714.1270986325.1270989003.575; __utmz=174624884.1264524375.411.12.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=low%20stakes%20poker%20videos; phpbb3_cmviy_k=; phpbb3_cmviy_u=2; phpbb3_cmviy_sid=d8df5c0943863004ca40ef9c392d371d; __utmb=174624884.4.10.1270989003; __utmc=174624884
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Date: Sun, 11 Apr 2010 12:57:41 GMT
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8l DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635
Last-Modified: Sun, 04 Apr 2010 12:51:06 GMT
Etag: "eb42d6-7d9b843-48368aa6dc280"
Accept-Ranges: bytes
Content-Length: 131708995
Keep-Alive: timeout=10, max=30
Connection: Keep-Alive
Content-Type: video/x-ms-wmv
And here's what they look like for the request answered by my script:
http://www.grinderschool.com/download_video_test.php?t=KillsAids021&format=wmv
GET /download_video_test.php?t=KillsAids021&format=wmv HTTP/1.1
Host: www.grinderschool.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: style_cookie=printonly; phpbb3_7c544_u=2; phpbb3_7c544_k=44b832912e5f887d; phpbb3_7c544_sid=e8852df42e08cc1b2250300c2897f78f; __utma=174624884.2719561324781918700.1251850714.1270986325.1270989003.575; __utmz=174624884.1264524375.411.12.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=low%20stakes%20poker%20videos; phpbb3_cmviy_k=; phpbb3_cmviy_u=2; phpbb3_cmviy_sid=d8df5c0943863004ca40ef9c392d371d; __utmb=174624884.4.10.1270989003; __utmc=174624884
HTTP/1.1 200 OK
Date: Sun, 11 Apr 2010 12:58:02 GMT
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8l DAV/2 mod_auth_passthrough/2.1 FrontPage/5.0.2.2635
X-Powered-By: PHP/5.2.11
Content-Disposition: attachment; filename=KillsAids021.wmv
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=10, max=30
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: video/x-ms-wmv
So the question is...what can I do to make downloads from the script work properly? Again, for 99% of users, it works as is (though I find it annoying now that no filesize is reported and thus that no time estimate can be computed about the download).

It's your GZIP compression. When you specify a content length but turn compression on, it gums everything up. It's happened to me a few times: try turning it off in your script.
Generally you'd turn it on with:
ob_start("ob_gzhandler");
...so just comment that line out. If that's not in your code, chances are there's a setting in either your php.ini file somewhere or your apache.conf/conf.d.
Hope this helps!

Content-Encoding: gzip
Hmm. Presumably PHP's zlib.output_compression is doing that. (Doesn't look like Apache's mod_deflate.)
Try turning it off and seeing if it's that that's forcing chunked encoding. You don't want to compress the download of a filetype like WMV which is already highly compressed.
However, chunked encoding would only explain the lack of size report. The download should still work. Is it possible you're being hit by a timeout (eg. PHP's set_time_limit, or Apache Timeout)?

If it is the script then have you tried using a substitute function for the readfile() function that reads and outputs a bit at a time? The reasoning behind this could be that a memory limit is reached somewhere and it fails.
From http://php.net/manual/en/function.readfile.php :
function readfile_chunked ($filename) {
$chunksize = 1*(1024*1024); // how many bytes per chunk
$buffer = '';
$handle = fopen($filename, 'rb');
if ($handle === false) {
return false;
}
while (!feof($handle)) {
$buffer = fread($handle, $chunksize);
print $buffer;
}
return fclose($handle);
}
Also, try to flush the output as often as you can.

Related

php - Output Compression problems

I'm facing a problem trying to use php output compression , I've been searching for many hours and I still have no clues...
Lets see a simple script :
<?php
$response = "abcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefgh";
if(function_exists('ob_gzhandler'))
{
ob_start('ob_gzhandler');
}
else {
ob_start();
}
echo $response;
ob_end_flush();
This is a method I've found all over the internet, and it used to work for me ... but not any more (and I've got no idea why) .
If i look at the http headers when I call this script :
Request :
Host: 192.168.51.191
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cache-Control: max-age=0
Response :
Connection: Keep-Alive
Content-Type: text/html
Date: Tue, 26 Jan 2016 15:19:07 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.9 (Win64) OpenSSL/1.0.1g PHP/5.5.12
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Powered-By: PHP/5.5.12
You can see that the response is NOT zipped (Firebird gives me a 0.06ko response), and the server sends the responses using chunked encoding.
I tried an alternate method to send zipped responses :
<?php
$response = "abcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefgh";
$replyBody = gzencode($response, 9, FORCE_GZIP);
header("Content-Encoding: gzip");
echo $replyBody;
And the response headers are as follow (the request headers are always the same):
Response :
Connection: Keep-Alive
Content-Type: text/html
Date: Tue, 26 Jan 2016 15:29:01 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.9 (Win64) OpenSSL/1.0.1g PHP/5.5.12
Transfer-Encoding: chunked
X-Powered-By: PHP/5.5.12
As you can see, this is basically the same behavior as in the first method.
Then if I try this :
<?php
$response = "abcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefghabcdefgh";
$replyBody = gzencode($response, 9, FORCE_GZIP);
echo $replyBody;
I receive something that looks like a zipped response (random characters), and the output size is 0.03ko .
Here a the corresponding response http headers :
Connection: Keep-Alive
Content-Length: 31
Content-Type: text/html
Date: Tue, 26 Jan 2016 15:32:46 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.9 (Win64) OpenSSL/1.0.1g PHP/5.5.12
X-Powered-By: PHP/5.5.12
It lets me think that the zipping part is working correctly because the output size has been reduced (it is obviously not readable because the browser can't know that it is zipped content).
That's where I'm lost ...
If I understand it right, when I manually send zipped data (using gzencode) , If I set the header"Content-Encoding: gzip" , the webserver/php seems to UNZIP it before sending it to the browser ??? How is it possible ?
And Why is it sending it as "chunked" data instead of setting the Content-Length header ?
I tried to set the Content-Length manually in the response; it doesn't change anything (it won't appear in the response headers, I'll still have a "chunked" response.
I've seen somewhere that I have to write the "Content-Length" header before sending other data or header to avoid the "chunked" response, I tried it and still had the same results.
I thought it could be a problem with BOM characters at the beginning of my php test script, but it is saved in UTF-8 without BOM encoding so I don't think it 's the problem.
I have this problem on my dev computer (using wampserver) AND in the production environment (IIS), previously it was working on both servers.
I have this problem using several browsers, and I checked the response sizes I wrote previously with fiddler.
Does anyone see where the problem could be ?
Thanks in advance
I'd go through the following checklist if I were you.
1. Check zlib extension is installed or not.
ob_gzhandler needs the zlib extension to work. Without which it just silently falls back to default settings.
2. Verify that you don't have zlib.output_compression enabled in your php.ini.
As explained here, even though zlib.output_compression is preferred over ob_gzhandler(), you can not use both simultaneously. So your code becomes..
if (extension_loaded('zlib') && !ini_get('zlib.output_compression')){
ob_start('ob_gzhandler');
}
3. Check if headers have already been sent eg. something got output-ted before the
ob_start(ob_gzhandler) This will prevent the compressed output from being detected as such. eg. Having some character before <?php or an echo somewhere up in the code.
4. Make sure you aren't using all of the above in addition to the gzipping in apache(mod_deflate).
This will only cause the output to be double gzipped which most probably will confuse the browser.

What to blame? PHP/Apache or Chrome or Magento?

This is as very odd problem folks.. it effects only chrome, and only pages served in PHP.
I made a page which is just pure html being served with the same assets in the same dir as the handled page just because I was not sure what to do about the situation:
http://www.sublimewellness.ca/store/debug.html
www.sublimewellness.ca/store/
The page works just fine on other browsers but fails on chrome.
You will notice the page does not load on chrome (you can see the white screen and the html dump though).
If you get no response, its probably because magento is a beast and other stack exchange people are hitting it.
Here are the request headers..
GET /store/ HTTP/1.1
Host: www.sublimewellness.ca
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Cookie: frontend=47oojlnfi9aji3c85e3as98d63
HTTP/1.1 200 OK
Date: Tue, 10 Sep 2013 08:01:43 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: frontend=47oojlnfi9aji3c85e3as98d63; expires=Tue, 10-Sep-2013 09:01:45 GMT; path=/store; domain=www.sublimewellness.ca; httponly
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
What to blame? I dont think its javascript, or the page dump html that is causing a random issue as the html page indicates its not a problem.
I dont think its PHP?
Its clearly not mysql.
Im putting my hands towards some sort of apache header.
I dont really want to just throw out other project specific code unless requested. Please let me know what you feel you need to know or what you would look for first and I will investigate and post what you need.
Should note that on rare occasion the page does load correctly in chrome!

PHP Download Script Works But Client Browser Does Not Download

This script is for my http file server. I have my files out of web root, so I am using a php script to grab and send the files to the client. The problem is, when I click on the file to download the browser(ff and chrome) does not ask me if I want to save the file. In chrome's web tools, under network, I see that the download.php did execute successfully. In fact, I even see where the file was transfered in bytes for the request. But the downloaded file is not on the client computer. Why isn't the browser client asking/downloading the file?
Web server is Nginx.
<?php
$path = "/trunk/";
$file = $_POST['filename'];
$file_ext = pathinfo($file, PATHINFO_EXTENSION);
$file_name = pathinfo($file, PATHINFO_BASENAME);
$file_full = $path . $file_name;
$finfo = new finfo(FILEINFO_MIME_TYPE);
$ctype = $finfo -> file($file_full);
header("Content-Disposition: attachment; filename=\"".$file_name."\"");
header("Content-Type: " .$ctype);
header("Content-Length: " .filesize($file_full));
error_log(filesize($file_full));
readfile($file_full);
?>
Request Header:
POST /php/download.php HTTP/1.1
Host: www.example.com
Connection: keep-alive
Content-Length: 146
Origin: https://www.example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryMA7u5AkYPL9qGmRY
Accept: */*
Referer: https://www.example.com/index.php
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
RESPONSE HEADER
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 01 Dec 2012 20:22:28 GMT
Content-Type: application/zip
Content-Length: 75090
Connection: keep-alive
Keep-Alive: timeout=300
X-Powered-By: PHP/5.4.6--pl0-gentoo
Content-Disposition: attachment; filename="try.zip"
Expires: Sat, 01 Dec 2012 20:22:27 GMT
Cache-Control: no-cache
Use Content-Type: application/octet-stream to guarantee a forced download across all browsers. If you know you are sending binary content (like your zip), then add Content-Transfer-Encoding: binary as well.

php redirection - HTML headers

I have many redirections within a VM webserver, which work when browsing the server with the embedded navigator (iceweasel). But that does not work when accessing the server from the hosting machine's browsers (tested with FF4/IE8/Chrome/Opera11).
All experienced redirecting methods are driving to a "server not available or overloaded" in the hosting machine browsers.
If you could have a look to the headers from the apache logs and give some hints about the differences (main one looks to be the GET url, provided that the same code is operating):
Working request leads to this log :
cat /var/log/apache2/access.log | grep 127 | grep random | tail -n1
127.0.0.1 - authuserid [26/Jun/2011:11:11:52 +0200]
"GET /index.php?page=100 HTTP/1.1" 200 49151
"https://www.mydomain.foo/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&random=c0117685e7e65a307989c219efc587b4&sid=n7en2it41h2gumrcq3kmmil3c0&sidf=.ps_AWDkIY"
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.19) Gecko/2011050718 Iceweasel/3.0.6 (Debian-3.0.6-3)"
Non working request leads to this log :
cat /var/log/apache2/access.log | grep 192 | grep random | tail -n1
www.mydomain.org:80 192.168.X.Y - authuserid [26/Jun/2011:11:08:07 +0200]
"GET /index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&random=685de8bcd4d198d6ad7f3cf4b23de5b7 HTTP/1.1" 302 -
"http://www.mydomain.foo/index.php?page=xyz"
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1"
I can't show the header response as I don't get a response and no error reported by apache (loglevel=error).
Thx
Controls done :
I have increased the browsers timeout (FF: network.http.keep-alive.timeout to 3600s : no change.
I checked that no headers were sent previously to the redirection : ok (a dump of headers_sent() shows no headers sent nor blank line or space in the includes, )
I have increased the Apache server timeout just in case: no change
I made sure of using an absolute url as of HTTP/1.1.
I tried php, html meta and js redirect: no change
EDIT 1:
Here are the headers as seen by LiveHTTPHeaders in the "non working" case :
http://www.mydomain.org/menus/noeud4.php
POST /menus/noeud4.php HTTP/1.1
Host: www.mydomain.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7
Keep-Alive: 3600
DNT: 1
Connection: keep-alive
Referer: http://www.mydomain.org/index.php?page=890
Cookie: PHPSESSID=4bge5gg1rgkit78k3seqlfcbq2
Authorization: Basic aW52aXRlZEBjYW1hY2FzYTp5b3VybXlndWVzdEB0b2RheQ==
Content-Type: application/x-www-form-urlencoded
Content-Length: 98
login=my_superlogin1&pwd1=vbigpass3xqz%40A2L&captcha=91690& source=noeud4.php&>formulaire_valide=SOUMETTRE
HTTP/1.1 302 Found
Date: Sun, 26 Jun 2011 14:17:27 GMT
Server: Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 >mod_ssl/2.2.9 OpenSSL/0.9.8g PHP/5.3.3
X-Powered-By: PHP/5.3.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: http://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788
Content-Length: 0
Keep-Alive: timeout=60
Connection: Keep-Alive
Content-Type: text/html
http://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788
GET /index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788 HTTP/1.1
Host: www.mydomain.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7
Keep-Alive: 3600
DNT: 1
Connection: keep-alive
Referer: http://www.mydomain.org/index.php?page=890
Cookie: PHPSESSID=4bge5gg1rgkit78k3seqlfcbq2
Authorization: Basic aW52aXRlZEBjYW1hY2FzYTp5b3VybXlndWVzdEB0b2RheQ==
HTTP/1.1 302 Found
Date: Sun, 26 Jun 2011 14:19:59 GMT
Server: Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_fastcgi/2.4.6 mod_python/3.3.1 Python/2.5.2 >mod_ssl/2.2.9 OpenSSL/0.9.8g PHP/5.3.3 X-Powered-By: PHP/5.3.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: https://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&sid=4bge5gg1rgkit78k3seqlfcbq2&sidf=.ps_Z5wRio
Content-Length: 0
Keep-Alive: timeout=60
Connection: Keep-Alive
Content-Type: text/html
EDIT2:
Comparing both cases of request/responses (working/not working), I isolated the following 2 main differences among others :
On the "working" responses :
Status : 200
which I don't have on the "non working" reponse, but I do not understand why.
on the "NON Working" response :
DNT:1
which stands for the option Do Not Track (me) from FF4.
So I tried to deactivate this option, but same result.
I may miss sthg for sure. All looks as if the server was down. Maybe the session cookie (76 kb) is too big. I also tried downgrading firefox 4 to 3.6 as this another changed parameter, but I still get the same response with FF3.6 as FF4.
As you can see in the requests you posted you try to hit:
http://www.mydomain.org/menus/noeud4.php
but you get redirected to http://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788 and then again to https://www.mydomain.org/index.php?page=100&new_session=a4da9106dba2ffd40345a5eb624d7788&sid=4bge5gg1rgkit78k3seqlfcbq2&sidf=.ps_Z5wRio
Does it keep sending out 302 headers?
I'm guessing the noeud4.php script is some login script that will likely create a session and probably set some cookies. My guess would be to check if that is being done correctly - and figure out why it's throwing the 302.

PHP Query String Limit

I have PHP 5.1.6 (cli) installed and whenever the GET query string is more than 128 characters it fails with HTTP 406 Not Acceptable error. Any suggestions how I can fix this so can use more than 128 characters? POST is not an option.
The error is being returned by the server so don't think it's browser issue.
And the reason I think it's PHP and not Apache is because it works fine with an HTML file.
GET /test.php?phptestof129characterstring-NEW-WOVEN-FENCE-PANELS-GARDEN_W0QQitemZ200303392512QQihZ010QQcategoryZ139954QQtcZphotoQQcmdZViewItem
HTTP/1.1
Host: *****
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: agent_name=Tim
HTTP/1.1 406 Not Acceptable
Date: Tue, 03 Feb 2009 12:05:33 GMT
Server: Apache/2.2.3 (Red Hat)
X-Powered-By: PHP/5.1.6
Content-Length: 0
Connection: close
Content-Type: text/html
GET /test.html?phptestof129characterstring-NEW-WOVEN-FENCE-PANELS-GARDEN_W0QQitemZ200303392512QQihZ010QQcategoryZ139954QQtcZphotoQQcmdZViewItem
HTTP/1.1
Host: *****
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: agent_name=Tim
HTTP/1.1 200 OK
Date: Tue, 03 Feb 2009 12:18:19 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Fri, 19 Dec 2008 15:01:17 GMT
ETag: "156960d-221-94be8940"
Accept-Ranges: bytes
Content-Length: 545
Connection: close
Content-Type: text/html
Do you have mod_security enabled on your webserver? It sounds like something it would do. If so, you may be able to disable locally inside your <VirtualHost> block or with an .htaccess file for v1.x
<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>
Version 2.x has different configuration syntax:
<IfModule mod_security2.c>
SecRuleEngine Off
</IfModule>
That's a bit of a brute force approach, you may want to read the documentation to see how you might allow particular URIs to pass through. See also Handling False Positives and Creating Custom Rules
As a work-around, you can try using Javascript to put the data in cookies. The cookies will be sent automatically with every GET request, and give you an extra 2KB of data space (if I'm not mistaken).
This is very risky if you don't want to transmit that data with every request, so generally speaking I would recommend against it.
It's a long shot, but try adding:
header('Content-Type: text/html');
to your server-side code. If that doesn't help, check your Apache configuration, maybe it's misconfigured so that PHP files can't emit text/html MIME type. If that doesn't help, how about setting up Apache so that .html files are treated as PHP and rename the target script to .html?
BTW, from http://www.checkupdown.com/status/E406.html :
A client (e.g. your Web browser or our CheckUpDown robot) can indicate to the Web server characteristics of the data it will accept back from the Web server. This is done using 'accept headers' of the following types:
Accept: The MIME types accepted by the client. For example, a browser may only accept back types of data (HTML files, GIF files etc.) it knows how to process.
Accept-Charset: The character sets accepted by the client.
Accept-Encoding: The data encoding accepted by the client e.g. the file formats it understands.
Accept-Language: The natural languages (English, German etc.) accepted by the client.
Accept-Ranges: Whether the client accepts ranges of bytes from the resource i.e. a portion of the resource.
If the Web server detects that the data it wants to return is not acceptable to the client, it returns a header containing the 406 error code.
Have found answer thanks to comment from Ben.
Although this generates 406 error:
test.php?129+characters
This works fine:
test.php?data=129+characters
So my guess is that in the first instance PHP is attempting to use the 129 characters as name in $_GET array whereas the second example has only 4 characters for the name and the rest is assigned as value, so array must have 128 character limit for index name.

Categories