#25863 [Fbk->Opn]: The specified CGI application misbehaved ...
ID: 25863
User updated by: salmanarshad2000 at yahoo dot com
Reported By: salmanarshad2000 at yahoo dot com
-Status: Feedback
+Status: Open
Bug Type: IIS related
Operating System: Windows XP, 2000
PHP Version: 4.3.3
New Comment:
I tried changing both cgi.* and IIS related settigs in the php.ini but
the problem remained there.
Previous Comments:
[2003-11-18 05:06:07] [EMAIL PROTECTED]
Check your cgi.* php.ini settings. Tuning those (set to opposite what
they are set right now) might help.
And for the record: I can not reproduce this.
[2003-11-18 00:38:09] salmanarshad2000 at yahoo dot com
The problem disappears totally if we use Apache, but some people just
don't like running two webservers on a machine at a time.
[2003-11-17 18:39:03] [EMAIL PROTECTED]
Try with Apache 1.3.29.
[2003-10-14 08:44:21] salmanarshad2000 at yahoo dot com
Description:
This bug or issue has been around for quite a while and seems like
nobody cares. The bug list is filled with hundreds of complains about
the "The specified CGI application misbehaved ..." error each time
these people have BOGUSed or CLOSEd saying things like "The version you
are using is too old, please try the latest version ...", "This is not
a php bug, please go to ...", "Not enough evidence ..." or "Problem
with Windows, not PHP". Quite a few versions of php have been released
in the meanwhile, but this issue hasn't been fixed, people who upgrade
their php installation come back with the same complains. I see no good
reason for this ignorance.
Problem Statement
-
When browsing a php application, the IIS server randomly throws the
error message:
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
Observations
This happened only when:
- PHP.exe is used as a CGI on IIS
- The php scripts contained 2 or more frames (e.g. phpMyAdmin)
- MySQL operation was executed (update, insert, delete etc.)
- header("Location: ...") is used to redirect user after a MySQL
operation to a page that also performs a MySQL operation
- The pages are viewed from local computer
- A very fast computer is used
This did not happened when:
- Apache server for windows with php support was used
- The php scripts contained 2 or more frames but all frames contained
php scripts with Hello World and a random number
- Frequency of errors was much lesser when same pages were accessed
from the network
- Pentium 2, 300 MHz was used (a slow computer)
History
---
Following bugs are all related to this problem. This is just a reminder
for the fact that this issue has been discussed quite a few times and
it is still present. People also found these interesting things that
might help to get the problem solved.
- BugID #25567 getting errors when doing a mysql_db_query() and then
header("location")
- BugID #24916 header("location")
- BugID #23208 using two or more frames
- BugID #19381 no details :(
- BugID #19676 works on one (slow) system but does not work on other
- BugID #18901 header("location") after delete or update, error occurs
under under load
- BugID #16313 header("location") and db operations
- BugID #23050 mysql_query() followed by header("location")
- BugID #17468 header("location")
- BugID #9852 thousands of lines describing the problem, including
frames, manually slowing down the script, pages work from outside the
machine nut not locally, two database connections in rapid succession
etc
Things that have been said earlier
--
"This is a problem with Microsoft OS"
No this is not, it works on exact same OS running on slower hardware or
when the application is accessed across a network. And even if it is,
the developers should try to find a work around instead of blaming M$
and telling it to fix it. After all, when you develop some app for an
environment, you don't change the environment to suit your app
(although sometimes it is easier to do so).
"This is not a php bug"
Well this could be right, since there is one other suspect, MySQL. But
somebody please figure out where the problem is? Also, MySQL is now an
integral part of php so problem could lie in the integration part.
My Opinion
---
May be php.exe is not fast enough to keep up with the pace at which IIS
can throw requests at it. Or ... may be it is a problem with the MySQL
connections ... atte
#25863 [Bgs->Opn]: The specified CGI application misbehaved ...
ID: 25863 User updated by: salmanarshad2000 at yahoo dot com Reported By: salmanarshad2000 at yahoo dot com -Status: Bogus +Status: Open Bug Type: IIS related Operating System: Windows XP, 2000 PHP Version: 4.3.3 New Comment: It is *not* a configuration problem, the webserver and php are configured properly and I am sure about that. I would like to know what test platform you are using? I request that you test the following case yourself: - Pentium 3/4 class machine with 256 MB RAM - Frameset containing 3 php pages, each performs a simple SELECT from a mySQL database Previous Comments: [2003-11-25 02:59:57] [EMAIL PROTECTED] Please, ask these support questions elsewhere. PHP as CGI works perfectly fine under IIS as long as both have been configured correctly. (I tested this myself..) [2003-11-24 04:44:57] salmanarshad2000 at yahoo dot com I tried changing both cgi.* and IIS related settigs in the php.ini but the problem remained there. [2003-11-18 05:06:07] [EMAIL PROTECTED] Check your cgi.* php.ini settings. Tuning those (set to opposite what they are set right now) might help. And for the record: I can not reproduce this. [2003-11-18 00:38:09] salmanarshad2000 at yahoo dot com The problem disappears totally if we use Apache, but some people just don't like running two webservers on a machine at a time. [2003-11-17 18:39:03] [EMAIL PROTECTED] Try with Apache 1.3.29. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/25863 -- Edit this bug report at http://bugs.php.net/?id=25863&edit=1
#25863 [Opn->Csd]: IIS: The specified CGI application misbehaved
ID: 25863
User updated by: salmanarshad2000 at yahoo dot com
Reported By: salmanarshad2000 at yahoo dot com
-Status: Open
+Status: Closed
Bug Type: CGI related
Operating System: win32 only
PHP Version: 4CVS, 5CVS, 6CVS..
New Comment:
Saw the problem for two more days after installing PHP version 4.3.4
(replacing version 4.3.3), after that the problem completely
disappeared.
Previous Comments:
[2003-12-12 16:46:57] nigel dot salt at hotmail dot com
I followed all the hints here but IIS 5 and PHP 5 would still not
behave. What was necessary in the end was:
1) Set
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Script
Map]
".php"="your path to php\\php.exe"
2) ensure there is not a php.ini in the windows system folder and that
there is one wherever you've put PHP
3) edit php.ini and set cgi force redirect to 0 and
cgi.rfc2616_headers = 1
4) Put the PHP scripts in their own folder underneath the inetpub root
5) Open the IIS console, right click your new php folder
In the Directory tab
set application name to the name of the folder
set executable and script as permission
set application protection to low
Click configuration and check that .php is mapped to wherever you put
PHP
Restart IIS
Try a very simple PHP page and it should work
Nigel
----
[2003-10-14 08:44:21] salmanarshad2000 at yahoo dot com
Description:
This bug or issue has been around for quite a while and seems like
nobody cares. The bug list is filled with hundreds of complains about
the "The specified CGI application misbehaved ..." error each time
these people have BOGUSed or CLOSEd saying things like "The version you
are using is too old, please try the latest version ...", "This is not
a php bug, please go to ...", "Not enough evidence ..." or "Problem
with Windows, not PHP". Quite a few versions of php have been released
in the meanwhile, but this issue hasn't been fixed, people who upgrade
their php installation come back with the same complains. I see no good
reason for this ignorance.
Problem Statement
-
When browsing a php application, the IIS server randomly throws the
error message:
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
Observations
This happened only when:
- PHP.exe is used as a CGI on IIS
- The php scripts contained 2 or more frames (e.g. phpMyAdmin)
- MySQL operation was executed (update, insert, delete etc.)
- header("Location: ...") is used to redirect user after a MySQL
operation to a page that also performs a MySQL operation
- The pages are viewed from local computer
- A very fast computer is used
This did not happened when:
- Apache server for windows with php support was used
- The php scripts contained 2 or more frames but all frames contained
php scripts with Hello World and a random number
- Frequency of errors was much lesser when same pages were accessed
from the network
- Pentium 2, 300 MHz was used (a slow computer)
History
---
Following bugs are all related to this problem. This is just a reminder
for the fact that this issue has been discussed quite a few times and
it is still present. People also found these interesting things that
might help to get the problem solved.
- BugID #25567 getting errors when doing a mysql_db_query() and then
header("location")
- BugID #24916 header("location")
- BugID #23208 using two or more frames
- BugID #19381 no details :(
- BugID #19676 works on one (slow) system but does not work on other
- BugID #18901 header("location") after delete or update, error occurs
under under load
- BugID #16313 header("location") and db operations
- BugID #23050 mysql_query() followed by header("location")
- BugID #17468 header("location")
- BugID #9852 thousands of lines describing the problem, including
frames, manually slowing down the script, pages work from outside the
machine nut not locally, two database connections in rapid succession
etc
Things that have been said earlier
--
"This is a problem with Microsoft OS"
No this is not, it works on exact same OS running on slower hardware or
when the application is accessed across a network. And even if it is,
the developers should try to find a work around instead of blaming M$
and telling it to fix it. After all, when you develop some app for an
environment, you don't change the environment to suit your app
(although sometimes it is easier to do so).
"This is not a php bug"
Well this could be right, since there is one other suspect, MySQL. But
somebody plea
#25567 [Com]: The specified CGI application misbehaved by not returning a complete set of HTT
ID: 25567 Comment by: salmanarshad2000 at yahoo dot com Reported By: alex dot baron at tusk dot com dot au Status: Bogus Bug Type: IIS related Operating System: Windows XP PHP Version: 4.3.3 New Comment: When I browse to phpmyadmin I receive the following error: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: I am using PHP:4.3.3 phpmyadmin: 2.5.3 mySQL: 3.23.32 (as reported by phpmyadmin) WebServer: IIS 5.1 OS: Win XP Professional, Service Pack 1 Hardware: Intel P4 2GHz with 256 MB RAM When I Right click -> Refresh individual frames the contents appear, except for the style sheet. However on occasions when I perform that refreshes two or more frames I again receive this error. I have other php applications running on same machine, including those developed by myself and they dont cause any problem... but if I refresh a page using the F5 button very quickly, 2-3 times a sec then this problem occurs on some refreshes. This same combination of php, mysql and phpmyadmin worked fine on a system with: WebServer: IIS 5.0 OS: Win 2000 Professional, Service Pack 3 Hardware: Intel P2 266MHz with 64 MB RAM Any ideas? BTW I read the comment aout having to remove the MS proxy client... I am using ISA Server client on both machines, but only the faster machine with Win XP causes this problem. Previous Comments: [2003-09-24 22:24:46] alex dot baron at tusk dot com dot au Well thanks For you help... not Anyway the issue lies with using microsft proxy client on the machine hosting the pages. This causes a CGI Header error. Removing the proxy client fixes the issue but prvents the developer from being able to access the outside via proxy. I hope this helps other people. A [2003-09-18 03:58:05] alex dot baron at tusk dot com dot au Sorry where are the error logs located? thanks A [2003-09-18 03:28:31] [EMAIL PROTECTED] That's access log, check the error log.. [2003-09-17 20:03:49] alex dot baron at tusk dot com dot au #Software: Microsoft Internet Information Services 5.1 Here are some more. #Version: 1.0 #Date: 2003-09-18 00:01:42 #Fields: time c-ip cs-method cs-uri-stem sc-status 00:01:42 192.168.0.45 GET /news/style.css 304 00:01:42 192.168.0.45 GET /news/admin/images/poweredbymysql.gif 304 00:01:42 192.168.0.45 GET /news/admin/newslisting.php 200 just thought the 200 might be important. Thanks Heaps A [2003-09-17 19:52:17] alex dot baron at tusk dot com dot au Cool From C:\WINDOWS\system32\Logfiles\W3SVC1 These entries are me using that app this morning. 23:49:13 192.168.0.45 GET /news/admin/ 302 23:49:13 192.168.0.45 GET /news/admin/ 302 23:49:15 192.168.0.45 GET /news/admin/index.php 200 23:49:15 192.168.0.45 GET /news/admin/index.php 200 23:49:15 192.168.0.45 GET /news/style.css 304 23:49:15 192.168.0.45 GET /news/admin/images/poweredbymysql.gif 304 23:49:17 192.168.0.45 GET /news/admin/newslisting.php 200 23:49:21 192.168.0.45 GET /news/admin/DBdeletenews.php 200 23:50:13 192.168.0.45 GET /news/admin/createnews.php 200 23:50:13 192.168.0.45 GET /news/admin/popup.js 304 23:50:14 192.168.0.45 POST /news/admin/DBcreatenews.php 302 23:50:14 192.168.0.45 GET /news/admin/newslisting.php 502 is that what you are looking for? Thanks A The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/25567 -- Edit this bug report at http://bugs.php.net/?id=25567&edit=1
#12061 [Com]: CGI Error
ID: 12061 Comment by: salmanarshad2000 at yahoo dot com Reported By: peters at connection dot ca Status: Bogus Bug Type: IIS related Operating System: Win 2K PHP Version: 4.0.6 New Comment: None of the tips and tricks mentioned here worked, though the phpMyAdmin people said that the solution is present somewhere on this page. I see three frames, each containing a "CGI Application Misbehaved ..." error whenever I try to view phpMyAdmin. However, if I refresh individual frames one by one in phpMyAdmin they appear, but this work around is not elegant. I believe that some thing goes wrong when simultaneous requests are thrown at php and it doesnot get a chance to complain. The confing I am using is: PHP:4.3.3 / win32 executable CGI MySQL: 3.23.32 phpMyAdmin: 2.5.3 Webserver: IIS 5.1 on Win XP Professional, SP1 Hardware: Intel P4, 2GHz The same software combination *was working* when I was using it on Win 2000 Profesional on Intel P2, 266MHz machine. Previous Comments: [2003-08-28 03:52:43] Jason dot Petit at Vaillant dot co dot uk OK, I was getting the exact same errors sometimes on both frames sometimes only on the left or right frame. I think I found what is causing it :P In config.inc.php you have the following line: $cfg['PmaAbsoluteUri'] = 'http://localhost/PHPMyAdmin'; Notice there is no "/" at the end but their example does. By removing the "/" my pages started to work 2 years late but I only just started using php. [2003-07-10 15:13:05] michael dot jensen at dnp-services dot com My 2 cents on the CGI error issue: The CGI error discussed here also happens, if you done everything strictly to the books (aka. install.txt), but have a multi-user setup on Windows 2k, and have your account within the Administrators (and probably any other restricted) group. Then, any new directory you create, inherits rights from your group. For IIS to be able to access your directory properly, you must have set access rights for "Everyone" for the folder where your php (or, for that matter, any other CGI) scripts are located. Allowing the default settings (for "Everyone") to be inherited while denying "Write" access rights (you don't want to have those) works fine for me. Using php -i, or php from the command line does NOT reveal this problem: it works just fine. The problem only occurs when you want to access the page from any browser. Hope it helps. Michael [2003-06-11 15:24:35] jwhatcher at hotmail dot com I am using advance server running iis on several machines with php. I understand that this error means many things. What does it mean when you get it intermit tingly? I go to the page and get the error. Refresh the page and it loads. It doesn't happen every time nor does it occur on the same page. But it happens frequent enough to be a problem. Is there any correlation between the exe version and the error. Reason I ask is because on one server I run the dll I have not had one single 502 in my log file. But with the exe it occurs every day. [2003-04-18 03:00:30] reznor at geeksanon dot ca Hello, I'm writing in regards to this error-> cgi error: The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: I've been to every message forum around the world and back and got nothing. What it did get me looking at lots was the php.ini file. I run a Win 2000 Server with the latest greast PHP 4.3.1 mySQL and IIS. When it hit me like a bull in a china shop, I've got this all up and running on my XP pro system to test my code on, let's look at that php.ini file, so I did. And I saw it. XP setting: doc_root = IIS setting: doc_root = C:\Inetpub\wwwroot OK so I set my IIS php.ini doc_root to the XP setting doc_root = ...and WaBLAM! It worked! [2003-02-26 14:06:32] garlandj at hotmail dot com The "misbehaving" error is generated from working with notepad, then saving the file: myphpfile.php What actually gets saved is this: myphpfile.php.txt Be sure to drop down the menu to All Files *.* to eliminate the default .txt extension from be appended. Alternatively, enable viewing of file-extensions and delete the .txt from the end of the file. I cannot however figure out the "undefined variable" problem with Windows 2000/XP. If you have a form and create a post action, the data should be passed so that: I should be able to use HTML like this: A
#25863 [NEW]: The specified CGI application misbehaved ...
From: salmanarshad2000 at yahoo dot com
Operating system: Windows XP, 2000
PHP version: 4.3.3
PHP Bug Type: IIS related
Bug description: The specified CGI application misbehaved ...
Description:
This bug or issue has been around for quite a while and seems like nobody
cares. The bug list is filled with hundreds of complains about the "The
specified CGI application misbehaved ..." error each time these people
have BOGUSed or CLOSEd saying things like "The version you are using is
too old, please try the latest version ...", "This is not a php bug,
please go to ...", "Not enough evidence ..." or "Problem with Windows, not
PHP". Quite a few versions of php have been released in the meanwhile, but
this issue hasn't been fixed, people who upgrade their php installation
come back with the same complains. I see no good reason for this
ignorance.
Problem Statement
-
When browsing a php application, the IIS server randomly throws the error
message:
CGI Error
The specified CGI application misbehaved by not returning a complete set
of HTTP headers. The headers it did return are:
Observations
This happened only when:
- PHP.exe is used as a CGI on IIS
- The php scripts contained 2 or more frames (e.g. phpMyAdmin)
- MySQL operation was executed (update, insert, delete etc.)
- header("Location: ...") is used to redirect user after a MySQL operation
to a page that also performs a MySQL operation
- The pages are viewed from local computer
- A very fast computer is used
This did not happened when:
- Apache server for windows with php support was used
- The php scripts contained 2 or more frames but all frames contained php
scripts with Hello World and a random number
- Frequency of errors was much lesser when same pages were accessed from
the network
- Pentium 2, 300 MHz was used (a slow computer)
History
---
Following bugs are all related to this problem. This is just a reminder
for the fact that this issue has been discussed quite a few times and it
is still present. People also found these interesting things that might
help to get the problem solved.
- BugID #25567 getting errors when doing a mysql_db_query() and then
header("location")
- BugID #24916 header("location")
- BugID #23208 using two or more frames
- BugID #19381 no details :(
- BugID #19676 works on one (slow) system but does not work on other
- BugID #18901 header("location") after delete or update, error occurs
under under load
- BugID #16313 header("location") and db operations
- BugID #23050 mysql_query() followed by header("location")
- BugID #17468 header("location")
- BugID #9852 thousands of lines describing the problem, including
frames, manually slowing down the script, pages work from outside the
machine nut not locally, two database connections in rapid succession etc
Things that have been said earlier
--
"This is a problem with Microsoft OS"
No this is not, it works on exact same OS running on slower hardware or
when the application is accessed across a network. And even if it is, the
developers should try to find a work around instead of blaming M$ and
telling it to fix it. After all, when you develop some app for an
environment, you don't change the environment to suit your app (although
sometimes it is easier to do so).
"This is not a php bug"
Well this could be right, since there is one other suspect, MySQL. But
somebody please figure out where the problem is? Also, MySQL is now an
integral part of php so problem could lie in the integration part.
My Opinion
---
May be php.exe is not fast enough to keep up with the pace at which IIS
can throw requests at it. Or ... may be it is a problem with the MySQL
connections ... attempting to create connections too quickly may be the
cause. Users having same problem please feel free to contribute with their
observations and suggestions.
--
Edit bug report at http://bugs.php.net/?id=25863&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25863&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25863&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25863&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25863&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25863&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25863&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25863&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25863&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25863&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25863&r=submittedtwice
register_globals:
#25863 [Fbk->Opn]: The specified CGI application misbehaved ...
ID: 25863 User updated by: salmanarshad2000 at yahoo dot com Reported By: salmanarshad2000 at yahoo dot com -Status: Feedback +Status: Open Bug Type: IIS related Operating System: Windows XP, 2000 PHP Version: 4.3.3 New Comment: Test Case 1: I open up my browser and type the following url: http://localhost/phpMyAdmin/index.php The frameset page opens up correctly (phpMyAdmin uses 3 frames) but inside each frame I see the following error: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: I right click in one frame and select "Refresh" and this time page appears normally (CSS was missing though). I repeat the process for other two frames and each one displays it's contents properly. Test Case 2 I type the following url: http://localhost/salman/netoffice/index.php (NetOffice 2.5.2 is available at www.sourceforge.net) The url changes to http://localhost/salman/netoffice/login.php CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: Refreshing the page opens the login page correctly. Test Case 3 I created a frameset page (container.php) with 9 frames each one of them calls frame.php?id= Inside frame.php there are simple echo statements and a loop of 1 to 1 No problem occurred this time, all frames loaded normally. Later I added a "SELECT * FROM Northwind.Customers" call to MS SQL Server 2000 in frame.php using mssql_*() functions and it worked fine too. Here is a snapshot of IIS5 log for test case 1 and 2, I thought it might be useful. #Software: Microsoft Internet Information Services 5.1 #Version: 1.0 #Date: 2003-10-15 09:46:45 #Fields: time c-ip cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status #-TEST CASE 1 09:46:45 127.0.0.1 GET /phpMyAdmin/css/phpmyadmin.css.php lang=en-iso-8859-1&js_frame=right 502 0 09:46:45 127.0.0.1 GET /phpMyAdmin/left.php lang=en-iso-8859-1&server=1&hash=ba564700538636f8eb738fc4ba3007851066211205 502 0 09:46:45 127.0.0.1 GET /phpMyAdmin/queryframe.php lang=en-iso-8859-1&server=1&hash=ba564700538636f8eb738fc4ba3007851066211205 502 0 09:46:45 127.0.0.1 GET /phpMyAdmin/main.php lang=en-iso-8859-1&server=1 502 0 09:46:45 127.0.0.1 GET /phpMyAdmin/index.php - 200 0 #-HERE I START RIGHT CLICK->REFRESH FRAME ONE BY ONE 09:46:49 192.168.0.2 GET /phpMyAdmin/css/phpmyadmin.css.php js_frame=left&num_dbs=0 502 0 09:46:49 192.168.0.2 GET /phpMyAdmin/images/pma_logo.png - 304 0 09:46:49 127.0.0.1 GET /phpMyAdmin/left.php lang=en-iso-8859-1&server=1&hash=ba564700538636f8eb738fc4ba3007851066211205 200 0 09:46:51 192.168.0.2 GET /phpMyAdmin/css/phpmyadmin.css.php lang=en-iso-8859-1&js_frame=right 502 0 09:46:51 127.0.0.1 GET /phpMyAdmin/main.php lang=en-iso-8859-1&server=1 200 0 09:46:53 192.168.0.2 GET /phpMyAdmin/css/phpmyadmin.css.php lang=en-iso-8859-1&js_frame=left&num_dbs=0 502 0 09:46:53 127.0.0.1 GET /phpMyAdmin/queryframe.php lang=en-iso-8859-1&server=1&hash=ba564700538636f8eb738fc4ba3007851066211205 200 0 #-TEST CASE 2 09:47:08 127.0.0.1 GET /salman/netoffice/index.php - 302 0 09:47:08 127.0.0.1 GET /salman/netoffice/general/login.php NETOFFICESID=5382ba70f133fd16fa30c171cd6cce3d 502 0 09:47:13 127.0.0.1 GET /salman/netoffice/javascript/general.js - 304 0 09:47:13 127.0.0.1 GET /salman/netoffice/javascript/overlib_mini.js - 304 0 09:47:13 127.0.0.1 GET /salman/netoffice/themes/default/stylesheet.css - 304 0 09:47:13 127.0.0.1 GET /salman/netoffice/themes/default/calendar.css - 304 0 09:47:13 127.0.0.1 GET /salman/netoffice/general/login.php NETOFFICESID=5382ba70f133fd16fa30c171cd6cce3d 200 0 09:47:27 127.0.0.1 POST /salman/netoffice/general/login.php auth=test&NETOFFICESID=5382ba70f133fd16fa30c171cd6cce3d 302 0 09:47:27 127.0.0.1 GET /salman/netoffice/reports/selecthours.php typeReports=custom&NETOFFICESID=5382ba70f133fd16fa30c171cd6cce3d 502 0 09:47:29 127.0.0.1 GET /salman/netoffice/javascript/calendar.js - 304 0 09:47:29 127.0.0.1 GET /salman/netoffice/javascript/general.js - 304 0 09:47:29 127.0.0.1 GET /salman/netoffice/javascript/overlib_mini.js - 304 0 09:47:29 127.0.0.1 GET /salman/netoffice/themes/default/stylesheet.css - 304 0 09:47:29 127.0.0.1 GET /salman/netoffice/themes/default/calendar.css - 304 0 09:47:29 127.0.0.1 GET /salman/netoffice/themes/default/spacer.gif - 304 0 09:47:29 127.0.0.1 GET /salman/netoffice/reports/selecthours.php typeReports=custom&NETOFFICESID=5382ba70f133fd16fa30c171cd6cce3d 200 0 Previous Comments: [2003-10-14 20:33:39] [EMAIL PROTECTED] Please provide short test case (all settings, script(s) whatever else is needed to reproduce this) so we can reproduce
#25863 [Opn]: The specified CGI application misbehaved ...
ID: 25863
User updated by: salmanarshad2000 at yahoo dot com
Reported By: salmanarshad2000 at yahoo dot com
Status: Open
-Bug Type: Feature/Change Request
+Bug Type: IIS related
Operating System: Windows XP, 2000
PHP Version: 4.3.3
New Comment:
Category changed from "Feature/Change Request" to "IIS Releted"
Previous Comments:
[2003-10-14 08:44:21] salmanarshad2000 at yahoo dot com
Description:
This bug or issue has been around for quite a while and seems like
nobody cares. The bug list is filled with hundreds of complains about
the "The specified CGI application misbehaved ..." error each time
these people have BOGUSed or CLOSEd saying things like "The version you
are using is too old, please try the latest version ...", "This is not
a php bug, please go to ...", "Not enough evidence ..." or "Problem
with Windows, not PHP". Quite a few versions of php have been released
in the meanwhile, but this issue hasn't been fixed, people who upgrade
their php installation come back with the same complains. I see no good
reason for this ignorance.
Problem Statement
-
When browsing a php application, the IIS server randomly throws the
error message:
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
Observations
This happened only when:
- PHP.exe is used as a CGI on IIS
- The php scripts contained 2 or more frames (e.g. phpMyAdmin)
- MySQL operation was executed (update, insert, delete etc.)
- header("Location: ...") is used to redirect user after a MySQL
operation to a page that also performs a MySQL operation
- The pages are viewed from local computer
- A very fast computer is used
This did not happened when:
- Apache server for windows with php support was used
- The php scripts contained 2 or more frames but all frames contained
php scripts with Hello World and a random number
- Frequency of errors was much lesser when same pages were accessed
from the network
- Pentium 2, 300 MHz was used (a slow computer)
History
---
Following bugs are all related to this problem. This is just a reminder
for the fact that this issue has been discussed quite a few times and
it is still present. People also found these interesting things that
might help to get the problem solved.
- BugID #25567 getting errors when doing a mysql_db_query() and then
header("location")
- BugID #24916 header("location")
- BugID #23208 using two or more frames
- BugID #19381 no details :(
- BugID #19676 works on one (slow) system but does not work on other
- BugID #18901 header("location") after delete or update, error occurs
under under load
- BugID #16313 header("location") and db operations
- BugID #23050 mysql_query() followed by header("location")
- BugID #17468 header("location")
- BugID #9852 thousands of lines describing the problem, including
frames, manually slowing down the script, pages work from outside the
machine nut not locally, two database connections in rapid succession
etc
Things that have been said earlier
--
"This is a problem with Microsoft OS"
No this is not, it works on exact same OS running on slower hardware or
when the application is accessed across a network. And even if it is,
the developers should try to find a work around instead of blaming M$
and telling it to fix it. After all, when you develop some app for an
environment, you don't change the environment to suit your app
(although sometimes it is easier to do so).
"This is not a php bug"
Well this could be right, since there is one other suspect, MySQL. But
somebody please figure out where the problem is? Also, MySQL is now an
integral part of php so problem could lie in the integration part.
My Opinion
---
May be php.exe is not fast enough to keep up with the pace at which IIS
can throw requests at it. Or ... may be it is a problem with the MySQL
connections ... attempting to create connections too quickly may be the
cause. Users having same problem please feel free to contribute with
their observations and suggestions.
--
Edit this bug report at http://bugs.php.net/?id=25863&edit=1
#25863 [Fbk->Opn]: The specified CGI application misbehaved ...
ID: 25863
User updated by: salmanarshad2000 at yahoo dot com
Reported By: salmanarshad2000 at yahoo dot com
-Status: Feedback
+Status: Open
Bug Type: IIS related
Operating System: Windows XP, 2000
PHP Version: 4.3.3
New Comment:
The problem disappears totally if we use Apache, but some people just
don't like running two webservers on a machine at a time.
Previous Comments:
[2003-11-17 18:39:03] [EMAIL PROTECTED]
Try with Apache 1.3.29.
[2003-10-14 08:44:21] salmanarshad2000 at yahoo dot com
Description:
This bug or issue has been around for quite a while and seems like
nobody cares. The bug list is filled with hundreds of complains about
the "The specified CGI application misbehaved ..." error each time
these people have BOGUSed or CLOSEd saying things like "The version you
are using is too old, please try the latest version ...", "This is not
a php bug, please go to ...", "Not enough evidence ..." or "Problem
with Windows, not PHP". Quite a few versions of php have been released
in the meanwhile, but this issue hasn't been fixed, people who upgrade
their php installation come back with the same complains. I see no good
reason for this ignorance.
Problem Statement
-
When browsing a php application, the IIS server randomly throws the
error message:
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
Observations
This happened only when:
- PHP.exe is used as a CGI on IIS
- The php scripts contained 2 or more frames (e.g. phpMyAdmin)
- MySQL operation was executed (update, insert, delete etc.)
- header("Location: ...") is used to redirect user after a MySQL
operation to a page that also performs a MySQL operation
- The pages are viewed from local computer
- A very fast computer is used
This did not happened when:
- Apache server for windows with php support was used
- The php scripts contained 2 or more frames but all frames contained
php scripts with Hello World and a random number
- Frequency of errors was much lesser when same pages were accessed
from the network
- Pentium 2, 300 MHz was used (a slow computer)
History
---
Following bugs are all related to this problem. This is just a reminder
for the fact that this issue has been discussed quite a few times and
it is still present. People also found these interesting things that
might help to get the problem solved.
- BugID #25567 getting errors when doing a mysql_db_query() and then
header("location")
- BugID #24916 header("location")
- BugID #23208 using two or more frames
- BugID #19381 no details :(
- BugID #19676 works on one (slow) system but does not work on other
- BugID #18901 header("location") after delete or update, error occurs
under under load
- BugID #16313 header("location") and db operations
- BugID #23050 mysql_query() followed by header("location")
- BugID #17468 header("location")
- BugID #9852 thousands of lines describing the problem, including
frames, manually slowing down the script, pages work from outside the
machine nut not locally, two database connections in rapid succession
etc
Things that have been said earlier
--
"This is a problem with Microsoft OS"
No this is not, it works on exact same OS running on slower hardware or
when the application is accessed across a network. And even if it is,
the developers should try to find a work around instead of blaming M$
and telling it to fix it. After all, when you develop some app for an
environment, you don't change the environment to suit your app
(although sometimes it is easier to do so).
"This is not a php bug"
Well this could be right, since there is one other suspect, MySQL. But
somebody please figure out where the problem is? Also, MySQL is now an
integral part of php so problem could lie in the integration part.
My Opinion
---
May be php.exe is not fast enough to keep up with the pace at which IIS
can throw requests at it. Or ... may be it is a problem with the MySQL
connections ... attempting to create connections too quickly may be the
cause. Users having same problem please feel free to contribute with
their observations and suggestions.
--
Edit this bug report at http://bugs.php.net/?id=25863&edit=1
#25863 [Csd]: IIS: The specified CGI application misbehaved
ID: 25863
User updated by: salmanarshad2000 at yahoo dot com
Reported By: salmanarshad2000 at yahoo dot com
Status: Closed
Bug Type: CGI related
Operating System: win32 only
PHP Version: 4CVS, 5CVS, 6CVS..
New Comment:
In my case, the problem disappeared mysteriously, after upgrading from
PHP 4.3.2 to PHP 4.3.3; No single line of code was changed. phpMyAdmin
and netOffice were the two applications that I had previously been
using and they caused the CGI misbehaved error frequently, but then the
problem disappeared after the upgrade.
Ok wait... I did other things too... upgrading php was a part of
maintainance operations I did in that time, other things include
removeing unnecessary programs, defragmenting hard disk, removing
unnecessary databases from mysql. Now I am not sure which one worked...
but I am not having that problem anymore. If I remember any thing else
I'll add it here.
Previous Comments:
[2004-04-27 18:32:08] david dot blair at nsi1 dot com
More information as I've had a chance to talk to our sa and users:
We've had the new pages (ones with images) up for a week and no one had
a problem until our IIS server puked last night.
After the reset, the CGI errors occurred only once per page.
ie: User Jay clicks thru to one of the pages that fits the conditions
described in this bug report...the server returns the CGI error. Jay
goes back and tries the page again, everything works fine...every user
after him sees the page okay.
But when a page is opened for the first time after the reset...it will
throw an error...this is only for pages that satisfy the conditions
I've posted earlier.
After about 28 hours from the reset, the users have self corrected the
problem by using the system...this might be what happened to
salmanarshad on his Jan. 27th post, but this doesn't explain why steve
on Apr. 23rd kept receiving the error until he removed the image tag...
[2004-04-27 16:15:02] david dot blair at nsi1 dot com
I can add onto / narrow down salmnarshad's info a bit:
I just had this error start popping up on pages where my main frame had
images added to it. I've had an image on the menu frame (which does not
get updated) and it hasn't caused any errors before.
In comparing against Salmnarshad's info my test cases are:
-Running PHP 4.3.4 on a 2000 server as CGI under IIS
-Running under 2 frames (only the main frame is being updated)
-I'm making MSSQL calls not MySQL calls on both the calling page, and
the next page displayed
-Using a header("Location: yada yada") redirect to move between pages
-The MSSQL connection is being closed just before the redirect, and
reopened right after it...it is not being left open
-Our server is running over 1ghz
-Pages are being viewed by client machines (errors have occurred
haphazardly on different clients, we have been unable to replicate the
error everytime)
Simplest solution seems like the easiest for me...I'm going to dump the
images from the pages that are causing this problem to try and resolve
it quickly on my end.
[2004-04-23 08:39:44] steve at xcvr dot com
I've had had this issue occur in my fresh installation of 4.3.6 (Win2K,
CGI), even after applying all the recommended
fixes/changes/configurations. So far, I've found that if I remove one
particular image, the problem goes away. Put the image back, and the
problem creeps up again. I've changed around the tag, and still
cannot get rid of the "...CGI application misbehaved...".
FWIW, this page uses SSL.
----------------
[2004-01-27 07:06:04] salmanarshad2000 at yahoo dot com
Saw the problem for two more days after installing PHP version 4.3.4
(replacing version 4.3.3), after that the problem completely
disappeared.
[2003-12-12 16:46:57] nigel dot salt at hotmail dot com
I followed all the hints here but IIS 5 and PHP 5 would still not
behave. What was necessary in the end was:
1) Set
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Script
Map]
".php"="your path to php\\php.exe"
2) ensure there is not a php.ini in the windows system folder and that
there is one wherever you've put PHP
3) edit php.ini and set cgi force redirect to 0 and
cgi.rfc2616_headers = 1
4) Put the PHP scripts in their own folder underneath the inetpub root
5) Open the IIS console, right click your new php folder
In the Directory tab
set application name to the name of the folder
set executable and script as permission
set application protection to low
Click configuration and c
#25863 [Csd->Opn]: IIS: The specified CGI application misbehaved
ID: 25863
User updated by: salmanarshad2000 at yahoo dot com
Reported By: salmanarshad2000 at yahoo dot com
-Status: Closed
+Status: Open
Bug Type: CGI related
Operating System: win32 only
PHP Version: 4CVS, 5CVS, 6CVS..
New Comment:
The same problem was also noticed on Windows Server 2003 machine with
IIS 6.0, php version 4.3.6, and mysql 3.2x.xx, faulting php application
is moodle (www.sourceforge.net). The "CGI application misbehaved" error
appears randomly on pages that contain lots of mysql_query() and
header( "location: " ).
Previous Comments:
[2004-09-08 16:41:34] [EMAIL PROTECTED]
People, please do not add comments to this bug report. If you have a
problem with the IIS documentation, see php bug #25863
[2004-09-08 10:06:25] roger dot gusthage at home dot se
I've solved me problem by adding a redirect file between my login page
and start page. This way it seems that my use of header("Location: yada
yada"); got some breathing room and could "catch" up and smoothly go to
my start page instead of throwing a CGI error ...
I use IIS 5, W2000 server with frames on start page and got the error
only when i used header-function above or when i refresh my page
quickly.
This is not the best solution, but could be usefull in login-situation
where i now put some text to tell the user that the login is
processing.
Redirect i used meta tag and only 1 sec delay.
Hope this might solve the problem for some of you.
[2004-06-29 12:03:00] closedbolt at gmx dot de
Seems like php.exe in php 5 rc3 does not prepend any headers.
--> cgi error in IIS
php-cgi.exe does... --> works fine for me now.
Example:
test.php
C:\php>php.exe test.php
hi
C:\php>php-cgi.exe test.php
Content-type: text/html
X-Powered-By: PHP/5.0.0RC3
hi
C:\php>
[2004-06-23 18:38:14] tincanmann at hotmail dot com
Hi, thanks for all the other posts and hopefully this can help someone
else!
I also struggled with this problem of getting PHP to run on IIS. I
solved it slightly differently on my development server to the live
production server, both running Win2003 Server (production being more
patched, secure, etc).
1) Ensure anonymous access not allowed by editing the website details
in IIS.
This solved my one server but not the other. However, it all seems to
stem from the security and permissions.
2) Try access the website using https:// instead of http:// ...
strange, I know, but it worked for the production server (and saved me
having to rewrite in ASP).
Gareth
[2004-05-26 15:36:11] onderoz at zmail dot sk
PHP5 Release candidate 2 + IIS5 on W2K Advanced Server.
Still having the same problem.. The damned CGI misbehaved bla bla bla..
I need a complete SOLUTION for this, not WORKAROUND, if we're talking
about a complete language.
What i did :
1.. Downloaded *latest* version of the PHP (5 RC2)
2.. Expanded zip file to the directory C:\PHP5\
3.. added paths to PATH as C:\PHP5;C:\PHP5\EXT as in folder tree.
4.. added extension .php and .php5 with c:\php5\php.exe %s %S
5.. added extension to HKEY_CLASSES_ROOT
6.. added pathinfo to HKEY_LOCAL_MACHINE
7.. gave permissions -full control- to IUSR_*, IWAM_*, EVERYONE on
C:\PHP5 and c:\inetpub\wwwroot\PHP5SCRIPTS
8.. edited php.ini file
a. cgi.force_redirect=0
b. ;doc_root=
so.. what's next?!?
1.. how should I get this system working with PHP?
2.. do I have to mess with these with every new
installation/upgrade/system change?
thanks folks, for *not* helping us newbies by not providing an
automated system for the installation process.
Onder
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/25863
--
Edit this bug report at http://bugs.php.net/?id=25863&edit=1
[PHP-BUG] Bug #63740 [NEW]: strtotime seems to use both sunday and monday as start of week
From: salmanarshad2000 at yahoo dot com
Operating system:
PHP version: 5.4.9
Package: Date/time related
Bug Type: Bug
Bug description:strtotime seems to use both sunday and monday as start of week
Description:
Weeks start on Sunday or Monday. However, in this regard:
1) strtotime behavior is not documented.
2) strtotime produces inconsistent results when "this week" is used.
Sample dates from month of December 2012 used the the test script:
Mon 2012-12-03
Tue 2012-12-04
Wed 2012-12-05
Thu 2012-12-06
Fri 2012-12-07
Sat 2012-12-08
Sun 2012-12-09
Mon 2012-12-10
Tue 2012-12-11
Wed 2012-12-12
Thu 2012-12-13
Fri 2012-12-14
Sat 2012-12-15
Sun 2012-12-16
Test script:
---
// function strtotime called on Sun 2012-12-09
echo date("D Y-m-d", strtotime("monday this week",
strtotime("2012-12-09"))); // Mon 2012-12-10
echo date("D Y-m-d", strtotime("sunday this week",
strtotime("2012-12-09"))); // Sun 2012-12-16
// function strtotime called on Mon 2012-12-10
echo date("D Y-m-d", strtotime("monday this week",
strtotime("2012-12-10"))); // Mon 2012-12-10
echo date("D Y-m-d", strtotime("sunday this week",
strtotime("2012-12-10"))); // Sun 2012-12-16
Expected result:
If Sunday is start of the week then "sunday this week" be less than "monday
this week":
// function strtotime called on Sun 2012-12-09
echo date("D Y-m-d", strtotime("monday this week",
strtotime("2012-12-09"))); // Mon 2012-12-10
echo date("D Y-m-d", strtotime("sunday this week",
strtotime("2012-12-09"))); // Sun 2012-12-09
// function strtotime called on Mon 2012-12-10
echo date("D Y-m-d", strtotime("monday this week",
strtotime("2012-12-10"))); // Mon 2012-12-10
echo date("D Y-m-d", strtotime("sunday this week",
strtotime("2012-12-10"))); // Sun 2012-12-09
If Monday is start of the week then "monday this week" should return
different values on sunday and monday:
// function strtotime called on Sun 2012-12-09
echo date("D Y-m-d", strtotime("monday this week",
strtotime("2012-12-09"))); // Mon 2012-12-03
echo date("D Y-m-d", strtotime("sunday this week",
strtotime("2012-12-09"))); // Sun 2012-12-09
// function strtotime called on Mon 2012-12-10
echo date("D Y-m-d", strtotime("monday this week",
strtotime("2012-12-10"))); // Mon 2012-12-10
echo date("D Y-m-d", strtotime("sunday this week",
strtotime("2012-12-10"))); // Sun 2012-12-16
Actual result:
--
See test script, actual result is present alongside each line.
--
Edit bug report at https://bugs.php.net/bug.php?id=63740&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63740&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63740&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63740&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63740&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63740&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63740&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63740&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63740&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63740&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63740&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63740&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63740&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63740&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63740&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63740&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63740&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63740&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63740&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63740&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63740&r=mysqlcfg
Bug #63740 [Com]: strtotime seems to use both sunday and monday as start of week
Edit report at https://bugs.php.net/bug.php?id=63740&edit=1
ID: 63740
Comment by: salmanarshad2000 at yahoo dot com
Reported by:salmanarshad2000 at yahoo dot com
Summary:strtotime seems to use both sunday and monday as
start of week
Status: Open
Type: Bug
Package:Date/time related
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
The latter part which explains that "Sunday this week" is evaluated as (i) this
week (ii) very next sunday is well explained and understandable.
The former part which mentions that "time argument of strtotime() such as this
week [is interpreted as] a week period of Monday through Sunday" is still
confusing. It does return a Monday but does it return the correct Monday?
/* when today is */
/* this week is */
/* Mon 2012-12-03 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-03"))); /* Mon 2012-12-03 */
/* Tue 2012-12-04 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-04"))); /* Mon 2012-12-03 */
/* Wed 2012-12-05 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-05"))); /* Mon 2012-12-03 */
/* Thu 2012-12-06 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-06"))); /* Mon 2012-12-03 */
/* Fri 2012-12-07 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-07"))); /* Mon 2012-12-03 */
/* Sat 2012-12-08 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-08"))); /* Mon 2012-12-03 */
/* Sun 2012-12-09 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-09"))); /* Mon 2012-12-10 */
/* Mon 2012-12-10 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-10"))); /* Mon 2012-12-10 */
/* Tue 2012-12-11 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-11"))); /* Mon 2012-12-10 */
/* Wed 2012-12-12 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-12"))); /* Mon 2012-12-10 */
/* Thu 2012-12-13 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-13"))); /* Mon 2012-12-10 */
/* Fri 2012-12-14 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-14"))); /* Mon 2012-12-10 */
/* Sat 2012-12-15 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-15"))); /* Mon 2012-12-10 */
/* Sun 2012-12-16 */ echo date("D Y-m-d", strtotime("this week",
strtotime("2012-12-16"))); /* Mon 2012-12-17 */
You can see that the output changes on Sundays, not Mondays. Expected:
"this week" on Sun 2012-12-09 should return the week starting Mon 2012-12-03
(ending on Sun 2012-12-09 inclusive)
"this week" on Sun 2012-12-16 should return the week starting Mon 2012-12-10
(ending on Sun 2012-12-16 inclusive)
Actual:
this week on Sun 2012-12-09 returns the week starting _coming_ Mon 2012-12-10
this week on Sun 2012-12-16 returns the week starting _coming_ Mon 2012-12-17
Previous Comments:
[2013-01-23 16:04:21] google...@php.net
I've actually recently updated the documentation about strtotime in regard to
this very
behavior. See Bug #52143.
The problem is that prior to PHP 5.3.0 the relative time formats "this week",
"next week",
"previous week" were taken to mean a 7 day period relative to the current time.
However,
the behavior was changed in PHP 5.3.0 to be interpreted as "a week period of
Monday
through Sunday". This is noted in the documentation for strtotime in the
changelog section
since last week.
http://php.net/manual/en/function.strtotime.php#refsect1-function.strtotime-changelog
We can see this behavior more clearly from the following code...
var_dump(date("D Y-m-d", strtotime("this week", strtotime("2012-12-08";
string(14) "Mon 2012-12-03"
var_dump(date("D Y-m-d", strtotime("this week", strtotime("2012-12-09";
string(14) "Mon 2012-12-10"
Here what you'll notice is that "this week" always starts on a Monday. Now,
when you want
make that format relative to a particular day of the week, let's say Sunday...
var_dump(date("D Y-m-d", strtotime("Sunday this week",
strtotime("2012-12-08";
string(14) "Sun 2012-12-09"
var_dump(date("D Y-
