FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » 404 error
Show: Today's Messages :: Polls :: Message Navigator
Switch to threaded view of this topic Create a new topic Submit Reply
404 error [message #185613] Tue, 22 April 2014 16:41 Go to next message
Ed Mullen is currently offline  Ed Mullen
Messages: 11
Registered: January 2014
Karma: 0
Junior Member
I have two sites on different hosts.

Both use identical code to display a "last modified" message. The code
is in a standard footer which is included (via PHP) on ever site page.

I just noticed something odd. At my site <http://edmullen.net> it works
just fine. The first link below shows a standard page with the footer
message. The second will produce an error page since the link doesn't
exist on the site. On the error page the date info is simply not displayed.

<http://edmullen.net/index.php>

<http://edmullen.net/bogus.php>

Fine so far. The other site has different results.

<http://guitarsnotguns.org/>

<http://guitarsnotguns.org/rot.php>

Notice the error message and incorrect date in the footer.

I'm guessing it's a server configuration issue. Any thoughts?

BTW, here's the PHP I use on both sites:

<?php
$current_file_name = ($_SERVER['REQUEST_URI']);
$current_path = ($_SERVER['DOCUMENT_ROOT']);
$full_name = $current_path.$current_file_name;
$last_modified = filemtime($full_name);
print("This page last changed: ");
print(date("F j, Y - h:i A", $last_modified));
?>

Thanks.

--
Ed Mullen
http://edmullen.net/
A fool-proof method for sculpting an elephant: First, get a huge block
of marble; then chip away everything that doesn't look like an elephant.
Re: 404 error [message #185614 is a reply to message #185613] Tue, 22 April 2014 16:58 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
On 4/22/2014 12:41 PM, Ed Mullen wrote:
> I have two sites on different hosts.
>
> Both use identical code to display a "last modified" message. The code
> is in a standard footer which is included (via PHP) on ever site page.
>
> I just noticed something odd. At my site <http://edmullen.net> it works
> just fine. The first link below shows a standard page with the footer
> message. The second will produce an error page since the link doesn't
> exist on the site. On the error page the date info is simply not
> displayed.
>
> <http://edmullen.net/index.php>
>
> <http://edmullen.net/bogus.php>
>
> Fine so far. The other site has different results.
>
> <http://guitarsnotguns.org/>
>
> <http://guitarsnotguns.org/rot.php>
>
> Notice the error message and incorrect date in the footer.
>
> I'm guessing it's a server configuration issue. Any thoughts?
>
> BTW, here's the PHP I use on both sites:
>
> <?php
> $current_file_name = ($_SERVER['REQUEST_URI']);
> $current_path = ($_SERVER['DOCUMENT_ROOT']);
> $full_name = $current_path.$current_file_name;
> $last_modified = filemtime($full_name);
> print("This page last changed: ");
> print(date("F j, Y - h:i A", $last_modified));
> ?>
>
> Thanks.
>

If the file doesn't exist, how can you get its time?

It looks like you're including your footer in the failing page, but not
in the working one. This is not a PHP issue.


--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
Re: 404 error [message #185615 is a reply to message #185614] Tue, 22 April 2014 17:25 Go to previous messageGo to next message
Ed Mullen is currently offline  Ed Mullen
Messages: 11
Registered: January 2014
Karma: 0
Junior Member
Jerry Stuckle wrote:
> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>> I have two sites on different hosts.
>>
>> Both use identical code to display a "last modified" message. The code
>> is in a standard footer which is included (via PHP) on ever site page.
>>
>> I just noticed something odd. At my site <http://edmullen.net> it works
>> just fine. The first link below shows a standard page with the footer
>> message. The second will produce an error page since the link doesn't
>> exist on the site. On the error page the date info is simply not
>> displayed.
>>
>> <http://edmullen.net/index.php>
>>
>> <http://edmullen.net/bogus.php>
>>
>> Fine so far. The other site has different results.
>>
>> <http://guitarsnotguns.org/>
>>
>> <http://guitarsnotguns.org/rot.php>
>>
>> Notice the error message and incorrect date in the footer.
>>
>> I'm guessing it's a server configuration issue. Any thoughts?
>>
>> BTW, here's the PHP I use on both sites:
>>
>> <?php
>> $current_file_name = ($_SERVER['REQUEST_URI']);
>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>> $full_name = $current_path.$current_file_name;
>> $last_modified = filemtime($full_name);
>> print("This page last changed: ");
>> print(date("F j, Y - h:i A", $last_modified));
>> ?>
>>
>> Thanks.
>>
>
> If the file doesn't exist, how can you get its time?
>

Agreed. Not expecting to.

> It looks like you're including your footer in the failing page, but not
> in the working one. This is not a PHP issue.
>
>

The footer is in the two good links above. The failing pages above do
not exist: They're links to a non-existant file. Hence the 404 result.

What I'm asking about is how the two hosts' servers handle it. The
first displays the custom 404 page WITHOUT showing the date in the
footer. No idea why.

The second host shows the 404 page but throws an error where the "date
modified" info should be. Obviously

--
Ed Mullen
http://edmullen.net/
Zen master to hot dog vendor: "Make me one with everything."
Re: 404 error [message #185616 is a reply to message #185615] Tue, 22 April 2014 17:32 Go to previous messageGo to next message
Ed Mullen is currently offline  Ed Mullen
Messages: 11
Registered: January 2014
Karma: 0
Junior Member
Ed Mullen wrote:
> Jerry Stuckle wrote:
>> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>> I have two sites on different hosts.
>>>
>>> Both use identical code to display a "last modified" message. The code
>>> is in a standard footer which is included (via PHP) on ever site page.
>>>
>>> I just noticed something odd. At my site <http://edmullen.net> it works
>>> just fine. The first link below shows a standard page with the footer
>>> message. The second will produce an error page since the link doesn't
>>> exist on the site. On the error page the date info is simply not
>>> displayed.
>>>
>>> <http://edmullen.net/index.php>
>>>
>>> <http://edmullen.net/bogus.php>
>>>
>>> Fine so far. The other site has different results.
>>>
>>> <http://guitarsnotguns.org/>
>>>
>>> <http://guitarsnotguns.org/rot.php>
>>>
>>> Notice the error message and incorrect date in the footer.
>>>
>>> I'm guessing it's a server configuration issue. Any thoughts?
>>>
>>> BTW, here's the PHP I use on both sites:
>>>
>>> <?php
>>> $current_file_name = ($_SERVER['REQUEST_URI']);
>>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>> $full_name = $current_path.$current_file_name;
>>> $last_modified = filemtime($full_name);
>>> print("This page last changed: ");
>>> print(date("F j, Y - h:i A", $last_modified));
>>> ?>
>>>
>>> Thanks.
>>>
>>
>> If the file doesn't exist, how can you get its time?
>>
>
> Agreed. Not expecting to.
>
>> It looks like you're including your footer in the failing page, but not
>> in the working one. This is not a PHP issue.
>>
>>
>
> The footer is in the two good links above. The failing pages above do
> not exist: They're links to a non-existant file. Hence the 404 result.
>
> What I'm asking about is how the two hosts' servers handle it. The
> first displays the custom 404 page WITHOUT showing the date in the
> footer. No idea why.
>
> The second host shows the 404 page but throws an error where the "date
> modified" info should be. Obviously
>

Oops. Hit send too fast.

I was going to say that obviously there is something different about the
servers set up.

I agree, it's probably not a PHP issue. Just thought the smart folks
here might have an idea.


--
Ed Mullen
http://edmullen.net/
"A conscience is like a boat or a car. If you feel you need one, rent
it." - J.R. Ewing
Re: 404 error [message #185618 is a reply to message #185616] Tue, 22 April 2014 18:35 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
On 4/22/2014 1:32 PM, Ed Mullen wrote:
> Ed Mullen wrote:
>> Jerry Stuckle wrote:
>>> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>>> I have two sites on different hosts.
>>>>
>>>> Both use identical code to display a "last modified" message. The code
>>>> is in a standard footer which is included (via PHP) on ever site page.
>>>>
>>>> I just noticed something odd. At my site <http://edmullen.net> it
>>>> works
>>>> just fine. The first link below shows a standard page with the footer
>>>> message. The second will produce an error page since the link doesn't
>>>> exist on the site. On the error page the date info is simply not
>>>> displayed.
>>>>
>>>> <http://edmullen.net/index.php>
>>>>
>>>> <http://edmullen.net/bogus.php>
>>>>
>>>> Fine so far. The other site has different results.
>>>>
>>>> <http://guitarsnotguns.org/>
>>>>
>>>> <http://guitarsnotguns.org/rot.php>
>>>>
>>>> Notice the error message and incorrect date in the footer.
>>>>
>>>> I'm guessing it's a server configuration issue. Any thoughts?
>>>>
>>>> BTW, here's the PHP I use on both sites:
>>>>
>>>> <?php
>>>> $current_file_name = ($_SERVER['REQUEST_URI']);
>>>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>>> $full_name = $current_path.$current_file_name;
>>>> $last_modified = filemtime($full_name);
>>>> print("This page last changed: ");
>>>> print(date("F j, Y - h:i A", $last_modified));
>>>> ?>
>>>>
>>>> Thanks.
>>>>
>>>
>>> If the file doesn't exist, how can you get its time?
>>>
>>
>> Agreed. Not expecting to.
>>
>>> It looks like you're including your footer in the failing page, but not
>>> in the working one. This is not a PHP issue.
>>>
>>>
>>
>> The footer is in the two good links above. The failing pages above do
>> not exist: They're links to a non-existant file. Hence the 404 result.
>>
>> What I'm asking about is how the two hosts' servers handle it. The
>> first displays the custom 404 page WITHOUT showing the date in the
>> footer. No idea why.
>>
>> The second host shows the 404 page but throws an error where the "date
>> modified" info should be. Obviously
>>
>
> Oops. Hit send too fast.
>
> I was going to say that obviously there is something different about the
> servers set up.
>
> I agree, it's probably not a PHP issue. Just thought the smart folks
> here might have an idea.
>
>

Then check in a server-related newsgroup. This isn't a PHP problem.


--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
Re: 404 error [message #185619 is a reply to message #185616] Tue, 22 April 2014 18:42 Go to previous messageGo to next message
Lew Pitcher is currently offline  Lew Pitcher
Messages: 60
Registered: April 2013
Karma: 0
Member
On Tuesday 22 April 2014 13:32, in comp.lang.php, "Ed Mullen"
<ejEVOMER(at)edmullen(dot)net> wrote:

> Ed Mullen wrote:
>> Jerry Stuckle wrote:
>>> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>>> I have two sites on different hosts.
>>>>
>>>> Both use identical code to display a "last modified" message. The code
>>>> is in a standard footer which is included (via PHP) on ever site page.
>>>>
>>>> I just noticed something odd. At my site <http://edmullen.net> it
>>>> works
>>>> just fine. The first link below shows a standard page with the footer
>>>> message. The second will produce an error page since the link doesn't
>>>> exist on the site. On the error page the date info is simply not
>>>> displayed.
>>>>
>>>> <http://edmullen.net/index.php>
>>>>
>>>> <http://edmullen.net/bogus.php>
>>>>
>>>> Fine so far. The other site has different results.
>>>>
>>>> <http://guitarsnotguns.org/>
>>>>
>>>> <http://guitarsnotguns.org/rot.php>
>>>>
>>>> Notice the error message and incorrect date in the footer.
>>>>
>>>> I'm guessing it's a server configuration issue. Any thoughts?
>>>>
>>>> BTW, here's the PHP I use on both sites:
>>>>
>>>> <?php
>>>> $current_file_name = ($_SERVER['REQUEST_URI']);
>>>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>>> $full_name = $current_path.$current_file_name;
>>>> $last_modified = filemtime($full_name);
>>>> print("This page last changed: ");
>>>> print(date("F j, Y - h:i A", $last_modified));
>>>> ?>
>>>>
>>>> Thanks.
>>>>
>>>
>>> If the file doesn't exist, how can you get its time?
>>>
>>
>> Agreed. Not expecting to.
>>
>>> It looks like you're including your footer in the failing page, but not
>>> in the working one. This is not a PHP issue.
>>>
>>>
>>
>> The footer is in the two good links above. The failing pages above do
>> not exist: They're links to a non-existant file. Hence the 404 result.
>>
>> What I'm asking about is how the two hosts' servers handle it. The
>> first displays the custom 404 page WITHOUT showing the date in the
>> footer. No idea why.
>>
>> The second host shows the 404 page but throws an error where the "date
>> modified" info should be. Obviously
>>
>
> Oops. Hit send too fast.
>
> I was going to say that obviously there is something different about the
> servers set up.
>
> I agree, it's probably not a PHP issue. Just thought the smart folks
> here might have an idea.


My (semi-educated) guess:

On edmullen.net, your php.ini file sets the error_reporting value to
E_ERROR, while on guitarsnotguns.org, the php.ini file sets the
error_reporting value to E_WARNING

E_ERROR settings will halt execution of the php script; if
filemtime($full_name) encounters a "file not found" error, the script
stops, and does not execute the subsequent printf() statements.


E_WARNING settings will not halt execution of the php script; if
filemtime($full_name) encounters a "file not found" error, the script
continues and tries execute the subsequent printf() statements.

Compare the php.ini settings (both explicit and implicit-default) from both
sites, especially the error_reporting and display_errors values, to see how
you've set PHP to handle errors.

HTH
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
Re: 404 error [message #185621 is a reply to message #185619] Tue, 22 April 2014 18:56 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
On 4/22/2014 2:42 PM, Lew Pitcher wrote:
> On Tuesday 22 April 2014 13:32, in comp.lang.php, "Ed Mullen"
> <ejEVOMER(at)edmullen(dot)net> wrote:
>
>> Ed Mullen wrote:
>>> Jerry Stuckle wrote:
>>>> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>>> > I have two sites on different hosts.
>>>> >
>>>> > Both use identical code to display a "last modified" message. The code
>>>> > is in a standard footer which is included (via PHP) on ever site page.
>>>> >
>>>> > I just noticed something odd. At my site <http://edmullen.net> it
>>>> > works
>>>> > just fine. The first link below shows a standard page with the footer
>>>> > message. The second will produce an error page since the link doesn't
>>>> > exist on the site. On the error page the date info is simply not
>>>> > displayed.
>>>> >
>>>> > <http://edmullen.net/index.php>
>>>> >
>>>> > <http://edmullen.net/bogus.php>
>>>> >
>>>> > Fine so far. The other site has different results.
>>>> >
>>>> > <http://guitarsnotguns.org/>
>>>> >
>>>> > <http://guitarsnotguns.org/rot.php>
>>>> >
>>>> > Notice the error message and incorrect date in the footer.
>>>> >
>>>> > I'm guessing it's a server configuration issue. Any thoughts?
>>>> >
>>>> > BTW, here's the PHP I use on both sites:
>>>> >
>>>> > <?php
>>>> > $current_file_name = ($_SERVER['REQUEST_URI']);
>>>> > $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>>> > $full_name = $current_path.$current_file_name;
>>>> > $last_modified = filemtime($full_name);
>>>> > print("This page last changed: ");
>>>> > print(date("F j, Y - h:i A", $last_modified));
>>>> > ?>
>>>> >
>>>> > Thanks.
>>>> >
>>>>
>>>> If the file doesn't exist, how can you get its time?
>>>>
>>>
>>> Agreed. Not expecting to.
>>>
>>>> It looks like you're including your footer in the failing page, but not
>>>> in the working one. This is not a PHP issue.
>>>>
>>>>
>>>
>>> The footer is in the two good links above. The failing pages above do
>>> not exist: They're links to a non-existant file. Hence the 404 result.
>>>
>>> What I'm asking about is how the two hosts' servers handle it. The
>>> first displays the custom 404 page WITHOUT showing the date in the
>>> footer. No idea why.
>>>
>>> The second host shows the 404 page but throws an error where the "date
>>> modified" info should be. Obviously
>>>
>>
>> Oops. Hit send too fast.
>>
>> I was going to say that obviously there is something different about the
>> servers set up.
>>
>> I agree, it's probably not a PHP issue. Just thought the smart folks
>> here might have an idea.
>
>
> My (semi-educated) guess:
>
> On edmullen.net, your php.ini file sets the error_reporting value to
> E_ERROR, while on guitarsnotguns.org, the php.ini file sets the
> error_reporting value to E_WARNING
>
> E_ERROR settings will halt execution of the php script; if
> filemtime($full_name) encounters a "file not found" error, the script
> stops, and does not execute the subsequent printf() statements.
>
>
> E_WARNING settings will not halt execution of the php script; if
> filemtime($full_name) encounters a "file not found" error, the script
> continues and tries execute the subsequent printf() statements.
>
> Compare the php.ini settings (both explicit and implicit-default) from both
> sites, especially the error_reporting and display_errors values, to see how
> you've set PHP to handle errors.
>
> HTH
>

Incorrect. An error will ALWAYS stop execution of the script, no matter
what the error_reporting value is. And a warning will NEVER stop
execution of the script, no matter what the error_reporting value is.

All this does is control what level of message is reported; it does not
affect execution in any way.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
Re: 404 error [message #185626 is a reply to message #185613] Tue, 22 April 2014 21:26 Go to previous messageGo to next message
Thomas 'PointedEars'  is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
Senior Member
Ed Mullen wrote:

> <http://edmullen.net/index.php>
> <http://edmullen.net/bogus.php>
>
> Fine so far. The other site has different results.
> […]
> http://guitarsnotguns.org/rot.php
>
> Notice the error message and incorrect date in the footer.

It is not an error message, it is a *warning*.

> I'm guessing it's a server configuration issue. Any thoughts?
>
> BTW, here's the PHP I use on both sites:
>
> <?php
> $current_file_name = ($_SERVER['REQUEST_URI']);
> $current_path = ($_SERVER['DOCUMENT_ROOT']);

It is pointless and confusing for people accustomed to writing PHP code to
put the RHS into parentheses here.

> $full_name = $current_path.$current_file_name;
> $last_modified = filemtime($full_name);

Look closely at that warning. This approach is not going to work reliably
because the HTTP request URI does not need to have anything to do with the
file path of the resource. In fact, there does not even need to be a real
file for a URI, the served content could have been generated entirely by PHP
(and usually is). As a result, in those cases filemtime() returns FALSE …

> print(date("F j, Y - h:i A", $last_modified));

… which date() converts to 0 (UNIX epoch) – as it expects an int (UNIX
timestamp), not a boolean value, for the second argument – and formats that
accordingly to “December 31, 1969” (not “January 1, 1970 - 12:00 AM”
probably because of timezone issues), which is then send to stdout by
print(). (You should use “echo” instead, unless in an expression where you
need “print”’s return value. Think sh, not perl.)

,----
| $ php -r 'echo date("F, j Y - h:i A", filemtime("Slartibartfast")) .
| "\n";'
| PHP Warning: filemtime(): stat failed for Slartibartfast in Command line
| code on line 1
| PHP Stack trace:
| PHP 1. {main}() Command line code:0
| PHP 2. filemtime() Command line code:1
| January, 1 1970 - 01:00 AM
|
| $ php -v
| PHP 5.5.11-3 (cli) (built: Apr 19 2014 16:46:26)
| Copyright (c) 1997-2014 The PHP Group
| Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
| with XCache v3.1.0, Copyright (c) 2005-2013, by mOo
| with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend
| Technologies
| with Xdebug v2.2.4, Copyright (c) 2002-2014, by Derick Rethans
| with XCache Optimizer v3.1.0, Copyright (c) 2005-2013, by mOo
| with XCache Cacher v3.1.0, Copyright (c) 2005-2013, by mOo
| with XCache Coverager v3.1.0, Copyright (c) 2005-2013, by mOo
`----

(I am in UTC+2 now because of European Summer Time, and date.timezone is set
to “Europe/Zurich”; the latter would account for the one-hour advance.)

You might be looking for filemtime(__FILE__) instead.

<http://php.net/phpinfo>
<http://php.net/filemtime>
<http://php.net/date>
<http://php.net/print>
<http://php.net/echo>
<http://php.net/manual/en/language.constants.predefined.php>


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Re: 404 error [message #185627 is a reply to message #185613] Tue, 22 April 2014 22:04 Go to previous messageGo to next message
Doug Miller is currently offline  Doug Miller
Messages: 171
Registered: August 2011
Karma: 0
Senior Member
Ed Mullen <ejEVOMER(at)edmullen(dot)net> wrote in news:7f2rl4(dot)2fb(dot)17(dot)1(at)news(dot)alt(dot)net:

[...]
> <http://guitarsnotguns.org/>

What in the world are "guitar snot guns" ?
Re: 404 error [message #185628 is a reply to message #185627] Tue, 22 April 2014 23:11 Go to previous messageGo to next message
The Natural Philosoph is currently offline  The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
Senior Member
On 22/04/14 23:04, Doug Miller wrote:
> Ed Mullen <ejEVOMER(at)edmullen(dot)net> wrote in news:7f2rl4(dot)2fb(dot)17(dot)1(at)news(dot)alt(dot)net:
>
> [...]
>> <http://guitarsnotguns.org/>
>
> What in the world are "guitar snot guns" ?
>
Dont ask...



--
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
Re: 404 error [message #185631 is a reply to message #185627] Wed, 23 April 2014 00:22 Go to previous messageGo to next message
Ed Mullen is currently offline  Ed Mullen
Messages: 11
Registered: January 2014
Karma: 0
Junior Member
Doug Miller wrote:
> Ed Mullen <ejEVOMER(at)edmullen(dot)net> wrote in news:7f2rl4(dot)2fb(dot)17(dot)1(at)news(dot)alt(dot)net:
>
> [...]
>> <http://guitarsnotguns.org/>
>
> What in the world are "guitar snot guns" ?
>

Cute.

Guitars Not Guns.

A legal non-profit involved in a serious cause, reducing childhood gun
violence.

When you stop mocking a legitimate organization feel free to donate.

--
Ed Mullen
http://edmullen.net/
Save your breath, you'll need it to blow up your date.
Re: 404 error [message #185632 is a reply to message #185621] Wed, 23 April 2014 06:56 Go to previous messageGo to next message
Anders Wegge Keller is currently offline  Anders Wegge Keller
Messages: 30
Registered: May 2012
Karma: 0
Member
Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:

> Incorrect. An error will ALWAYS stop execution of the script, no
> matter what the error_reporting value is. And a warning will NEVER
> stop execution of the script, no matter what the error_reporting value
> is.

filemtime

(PHP 4, PHP 5)
filemtime — Gets file modification time

....

Errors/Exceptions ¶

Upon failure, an E_WARNING is emitted.

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*
Re: 404 error [message #185633 is a reply to message #185632] Wed, 23 April 2014 11:12 Go to previous messageGo to next message
Thomas 'PointedEars'  is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
Senior Member
Anders Wegge Keller wrote:

> Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
>> Incorrect. An error will ALWAYS stop execution of the script, no
>> matter what the error_reporting value is. And a warning will NEVER
>> stop execution of the script, no matter what the error_reporting value
>> is.
>
> filemtime
>
> (PHP 4, PHP 5)
> filemtime — Gets file modification time
>
> ...
>
> Errors/Exceptions ¶
>
> Upon failure, an E_WARNING is emitted.

What are you getting at?


PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
Re: 404 error [message #185634 is a reply to message #185633] Wed, 23 April 2014 11:23 Go to previous messageGo to next message
Anders Wegge Keller is currently offline  Anders Wegge Keller
Messages: 30
Registered: May 2012
Karma: 0
Member
Thomas 'PointedEars' Lahn <PointedEars(at)web(dot)de> writes:

> Anders Wegge Keller wrote:
>
>> Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
>>> Incorrect. An error will ALWAYS stop execution of the script, no
>>> matter what the error_reporting value is. And a warning will NEVER
>>> stop execution of the script, no matter what the error_reporting value
>>> is.
>>
>> filemtime
>>
>> (PHP 4, PHP 5)
>> filemtime — Gets file modification time
>>
>> ...
>>
>> Errors/Exceptions ¶
>>
>> Upon failure, an E_WARNING is emitted.
>
> What are you getting at?

Pointing out the futility of discussing E_ERROR in this case.

/Wegge

Leder efter redundant peering af dk.*,linux.debian.*
Re: 404 error [message #185635 is a reply to message #185634] Wed, 23 April 2014 11:36 Go to previous messageGo to next message
Thomas 'PointedEars'  is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
Senior Member
Anders Wegge Keller wrote:

> Thomas 'PointedEars' Lahn <PointedEars(at)web(dot)de> writes:
>> Anders Wegge Keller wrote:
>>> Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
>>>> Incorrect. An error will ALWAYS stop execution of the script, no
>>>> matter what the error_reporting value is. And a warning will NEVER
>>>> stop execution of the script, no matter what the error_reporting value
>>>> is.
>>>
>>> filemtime
>>>
>>> (PHP 4, PHP 5)
>>> filemtime — Gets file modification time
>>>
>>> ...
>>>
>>> Errors/Exceptions ¶
>>>
>>> Upon failure, an E_WARNING is emitted.
>>
>> What are you getting at?
>
> Pointing out the futility of discussing E_ERROR in this case.

But the point made here was that error_reporting settings do not influence
php’s behavior with regard to the program flow per se, only which
errors/warnings/notices will be reported by php. The opposite had been
assumed by Lew Pitcher.

One should not misconstrue the generic format of the documentation or the
identifiers or values of error constants as proof that errors, warnings and
notices would be *functionally* the same.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Re: 404 error [message #185636 is a reply to message #185632] Wed, 23 April 2014 12:08 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
On 4/23/2014 2:56 AM, Anders Wegge Keller wrote:
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
>
>> Incorrect. An error will ALWAYS stop execution of the script, no
>> matter what the error_reporting value is. And a warning will NEVER
>> stop execution of the script, no matter what the error_reporting value
>> is.
>
> filemtime
>
> (PHP 4, PHP 5)
> filemtime — Gets file modification time
>
> ...
>
> Errors/Exceptions ¶
>
> Upon failure, an E_WARNING is emitted.
>

Which has absolutely nothing to do with what I said...


--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
Re: 404 error [message #185637 is a reply to message #185634] Wed, 23 April 2014 12:09 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
On 4/23/2014 7:23 AM, Anders Wegge Keller wrote:
> Thomas 'PointedEars' Lahn <PointedEars(at)web(dot)de> writes:
>
>> Anders Wegge Keller wrote:
>>
>>> Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
>>>> Incorrect. An error will ALWAYS stop execution of the script, no
>>>> matter what the error_reporting value is. And a warning will NEVER
>>>> stop execution of the script, no matter what the error_reporting value
>>>> is.
>>>
>>> filemtime
>>>
>>> (PHP 4, PHP 5)
>>> filemtime — Gets file modification time
>>>
>>> ...
>>>
>>> Errors/Exceptions ¶
>>>
>>> Upon failure, an E_WARNING is emitted.
>>
>> What are you getting at?
>
> Pointing out the futility of discussing E_ERROR in this case.
>
> /Wegge
>
> Leder efter redundant peering af dk.*,linux.debian.*
>

So? Just trying to make yourself heard?


--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
Re: 404 error [message #185638 is a reply to message #185626] Wed, 23 April 2014 12:21 Go to previous messageGo to next message
Christoph Michael Bec is currently offline  Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
Senior Member
Thomas 'PointedEars' Lahn:

> Look closely at that warning. This approach is not going to work reliably
> because the HTTP request URI does not need to have anything to do with the
> file path of the resource. In fact, there does not even need to be a real
> file for a URI, the served content could have been generated entirely by PHP
> (and usually is). As a result, in those cases filemtime() returns FALSE …

ACK.

> You might be looking for filemtime(__FILE__) instead.

__FILE__ contains the filepath of the currently *included* file; in Ed's
case the following should be more appropriate:

filemtime($_SERVER['SCRIPT_NAME']);

--
Christoph M. Becker
Re: 404 error [message #185639 is a reply to message #185638] Wed, 23 April 2014 13:12 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
On 4/23/2014 8:21 AM, Christoph Michael Becker wrote:
> Thomas 'PointedEars' Lahn:
>
>> Look closely at that warning. This approach is not going to work reliably
>> because the HTTP request URI does not need to have anything to do with the
>> file path of the resource. In fact, there does not even need to be a real
>> file for a URI, the served content could have been generated entirely by PHP
>> (and usually is). As a result, in those cases filemtime() returns FALSE …
>
> ACK.
>
>> You might be looking for filemtime(__FILE__) instead.
>
> __FILE__ contains the filepath of the currently *included* file; in Ed's
> case the following should be more appropriate:
>

True - which in this case would be the footer, not the requested page.

> filemtime($_SERVER['SCRIPT_NAME']);
>

Unfortunately, this, too, may or may not have any relationship to the
file system.


--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
Re: 404 error [message #185640 is a reply to message #185638] Wed, 23 April 2014 13:56 Go to previous messageGo to next message
Thomas 'PointedEars'  is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
Senior Member
Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn:
>> You might be looking for filemtime(__FILE__) instead.
>
> __FILE__ contains the filepath of the currently *included* file; in Ed's
> case the following should be more appropriate:
>
> filemtime($_SERVER['SCRIPT_NAME']);

IBTD. Who is to tell that he did not want the modification time of an
include? As it is, the code makes no sense anyway, even with the
corrections I suggested.

I find it hard to believe that anyone is interested in the last modification
date of a script that generates error documents; I find it more probable
that one wants to output the date and time when the error document was
generated, so that the user can make the connection between the availability
of the requested resource and the date of the request. If so, filemtime()
is the wrong approach; mktime() or (better) gmmktime() should be used
instead.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(at)news(dot)demon(dot)co(dot)uk>
Re: 404 error [message #185641 is a reply to message #185640] Wed, 23 April 2014 16:00 Go to previous messageGo to next message
Christoph Michael Bec is currently offline  Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
Senior Member
Thomas 'PointedEars' Lahn wrote:

> Christoph Michael Becker wrote:
>
>> Thomas 'PointedEars' Lahn:
>>> You might be looking for filemtime(__FILE__) instead.
>>
>> __FILE__ contains the filepath of the currently *included* file; in Ed's
>> case the following should be more appropriate:
>>
>> filemtime($_SERVER['SCRIPT_NAME']);
>
> IBTD. Who is to tell that he did not want the modification time of an
> include? As it is, the code makes no sense anyway, even with the
> corrections I suggested.

In <news:7f2rl4(dot)2fb(dot)17(dot)1(at)news(dot)alt(dot)net> Ed Mullen wrote:

> I have two sites on different hosts.
>
> Both use identical code to display a "last modified" message. The
> code is in a standard footer which is included (via PHP) on ever site
> page.

From that and the rest of the OP I assume, that the requested PHP
resource (rot.php) is stored as a file, and the last modification date
of this file should be displayed, what doesn't seem to be unreasonable
as long as it would be modified regarding the contained HTML, only.

--
Christoph M. Becker
Re: 404 error [message #185642 is a reply to message #185613] Wed, 23 April 2014 16:39 Go to previous messageGo to next message
Ed Mullen is currently offline  Ed Mullen
Messages: 11
Registered: January 2014
Karma: 0
Junior Member
Ed Mullen wrote:
> I have two sites on different hosts.
>
> Both use identical code to display a "last modified" message. The code
> is in a standard footer which is included (via PHP) on ever site page.
>
> I just noticed something odd. At my site <http://edmullen.net> it works
> just fine. The first link below shows a standard page with the footer
> message. The second will produce an error page since the link doesn't
> exist on the site. On the error page the date info is simply not
> displayed.

Thanks to all for the suggestions. I'll try them and see what happens.


--
Ed Mullen
http://edmullen.net/
After eating, do amphibians have to wait one hour before getting out of
the water?
Re: 404 error [message #185643 is a reply to message #185619] Wed, 23 April 2014 17:12 Go to previous messageGo to next message
Ed Mullen is currently offline  Ed Mullen
Messages: 11
Registered: January 2014
Karma: 0
Junior Member
Lew Pitcher wrote:
> On Tuesday 22 April 2014 13:32, in comp.lang.php, "Ed Mullen"
> <ejEVOMER(at)edmullen(dot)net> wrote:
>
>> Ed Mullen wrote:
>>> Jerry Stuckle wrote:
>>>> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>>> > I have two sites on different hosts.
>>>> >
>>>> > Both use identical code to display a "last modified" message. The code
>>>> > is in a standard footer which is included (via PHP) on ever site page.
>>>> >
>>>> > I just noticed something odd. At my site <http://edmullen.net> it
>>>> > works
>>>> > just fine. The first link below shows a standard page with the footer
>>>> > message. The second will produce an error page since the link doesn't
>>>> > exist on the site. On the error page the date info is simply not
>>>> > displayed.
>>>> >
>>>> > <http://edmullen.net/index.php>
>>>> >
>>>> > <http://edmullen.net/bogus.php>
>>>> >
>>>> > Fine so far. The other site has different results.
>>>> >
>>>> > <http://guitarsnotguns.org/>
>>>> >
>>>> > <http://guitarsnotguns.org/rot.php>
>>>> >
>>>> > Notice the error message and incorrect date in the footer.
>>>> >
>>>> > I'm guessing it's a server configuration issue. Any thoughts?
>>>> >
>>>> > BTW, here's the PHP I use on both sites:
>>>> >
>>>> > <?php
>>>> > $current_file_name = ($_SERVER['REQUEST_URI']);
>>>> > $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>>> > $full_name = $current_path.$current_file_name;
>>>> > $last_modified = filemtime($full_name);
>>>> > print("This page last changed: ");
>>>> > print(date("F j, Y - h:i A", $last_modified));
>>>> > ?>
>>>> >
>>>> > Thanks.
>>>> >
>>>>
>>>> If the file doesn't exist, how can you get its time?
>>>>
>>>
>>> Agreed. Not expecting to.
>>>
>>>> It looks like you're including your footer in the failing page, but not
>>>> in the working one. This is not a PHP issue.
>>>>
>>>>
>>>
>>> The footer is in the two good links above. The failing pages above do
>>> not exist: They're links to a non-existant file. Hence the 404 result.
>>>
>>> What I'm asking about is how the two hosts' servers handle it. The
>>> first displays the custom 404 page WITHOUT showing the date in the
>>> footer. No idea why.
>>>
>>> The second host shows the 404 page but throws an error where the "date
>>> modified" info should be. Obviously
>>>
>>
>> Oops. Hit send too fast.
>>
>> I was going to say that obviously there is something different about the
>> servers set up.
>>
>> I agree, it's probably not a PHP issue. Just thought the smart folks
>> here might have an idea.
>
>
> My (semi-educated) guess:
>
> On edmullen.net, your php.ini file sets the error_reporting value to
> E_ERROR, while on guitarsnotguns.org, the php.ini file sets the
> error_reporting value to E_WARNING
>
> E_ERROR settings will halt execution of the php script; if
> filemtime($full_name) encounters a "file not found" error, the script
> stops, and does not execute the subsequent printf() statements.
>
>
> E_WARNING settings will not halt execution of the php script; if
> filemtime($full_name) encounters a "file not found" error, the script
> continues and tries execute the subsequent printf() statements.
>
> Compare the php.ini settings (both explicit and implicit-default) from both
> sites, especially the error_reporting and display_errors values, to see how
> you've set PHP to handle errors.
>
> HTH
>

Indeed. When I do phpinfo on both hosts:

edmullen.net - error_reporting = 22517
guitarsnotguns.org - error_reporting = 30711

I haven't yet figured out how to get access to the php.ini file on
DreamHost, GNG's hosting service. Their documentation/help is somewhat
byzantine.

Thanks, Lew.

P.S. Googled and found that if I put this in the custom error pages as
the first line in "include" script it stops the error. The date is
still wrong but that's less annoying.

<?php error_reporting(22517); ?>



--
Ed Mullen
http://edmullen.net/
All those who believe in psychokinesis raise my hand.
Re: 404 error [message #185644 is a reply to message #185642] Wed, 23 April 2014 18:22 Go to previous messageGo to next message
Ed Mullen is currently offline  Ed Mullen
Messages: 11
Registered: January 2014
Karma: 0
Junior Member
Ed Mullen wrote:
> Ed Mullen wrote:
>> I have two sites on different hosts.
>>
>> Both use identical code to display a "last modified" message. The code
>> is in a standard footer which is included (via PHP) on ever site page.
>>
>> I just noticed something odd. At my site <http://edmullen.net> it works
>> just fine. The first link below shows a standard page with the footer
>> message. The second will produce an error page since the link doesn't
>> exist on the site. On the error page the date info is simply not
>> displayed.
>
> Thanks to all for the suggestions. I'll try them and see what happens.
>
>

Tried various things and decided to apply the KISS method. Made a
separate footer text file for the custom error files without the "last
modified" code in it.

--
Ed Mullen
http://edmullen.net/
Unable to close TROUSER.ZIP! - Replace floppy and retry (Y/N)?
Re: 404 error [message #185645 is a reply to message #185643] Wed, 23 April 2014 18:50 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
On 4/23/2014 1:12 PM, Ed Mullen wrote:
> Lew Pitcher wrote:
>> On Tuesday 22 April 2014 13:32, in comp.lang.php, "Ed Mullen"
>> <ejEVOMER(at)edmullen(dot)net> wrote:
>>
>>> Ed Mullen wrote:
>>>> Jerry Stuckle wrote:
>>>> > On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>>> >> I have two sites on different hosts.
>>>> >>
>>>> >> Both use identical code to display a "last modified" message. The
>>>> >> code
>>>> >> is in a standard footer which is included (via PHP) on ever site
>>>> >> page.
>>>> >>
>>>> >> I just noticed something odd. At my site <http://edmullen.net> it
>>>> >> works
>>>> >> just fine. The first link below shows a standard page with the
>>>> >> footer
>>>> >> message. The second will produce an error page since the link
>>>> >> doesn't
>>>> >> exist on the site. On the error page the date info is simply not
>>>> >> displayed.
>>>> >>
>>>> >> <http://edmullen.net/index.php>
>>>> >>
>>>> >> <http://edmullen.net/bogus.php>
>>>> >>
>>>> >> Fine so far. The other site has different results.
>>>> >>
>>>> >> <http://guitarsnotguns.org/>
>>>> >>
>>>> >> <http://guitarsnotguns.org/rot.php>
>>>> >>
>>>> >> Notice the error message and incorrect date in the footer.
>>>> >>
>>>> >> I'm guessing it's a server configuration issue. Any thoughts?
>>>> >>
>>>> >> BTW, here's the PHP I use on both sites:
>>>> >>
>>>> >> <?php
>>>> >> $current_file_name = ($_SERVER['REQUEST_URI']);
>>>> >> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>>> >> $full_name = $current_path.$current_file_name;
>>>> >> $last_modified = filemtime($full_name);
>>>> >> print("This page last changed: ");
>>>> >> print(date("F j, Y - h:i A", $last_modified));
>>>> >> ?>
>>>> >>
>>>> >> Thanks.
>>>> >>
>>>> >
>>>> > If the file doesn't exist, how can you get its time?
>>>> >
>>>>
>>>> Agreed. Not expecting to.
>>>>
>>>> > It looks like you're including your footer in the failing page, but
>>>> > not
>>>> > in the working one. This is not a PHP issue.
>>>> >
>>>> >
>>>>
>>>> The footer is in the two good links above. The failing pages above do
>>>> not exist: They're links to a non-existant file. Hence the 404
>>>> result.
>>>>
>>>> What I'm asking about is how the two hosts' servers handle it. The
>>>> first displays the custom 404 page WITHOUT showing the date in the
>>>> footer. No idea why.
>>>>
>>>> The second host shows the 404 page but throws an error where the "date
>>>> modified" info should be. Obviously
>>>>
>>>
>>> Oops. Hit send too fast.
>>>
>>> I was going to say that obviously there is something different about the
>>> servers set up.
>>>
>>> I agree, it's probably not a PHP issue. Just thought the smart folks
>>> here might have an idea.
>>
>>
>> My (semi-educated) guess:
>>
>> On edmullen.net, your php.ini file sets the error_reporting value to
>> E_ERROR, while on guitarsnotguns.org, the php.ini file sets the
>> error_reporting value to E_WARNING
>>
>> E_ERROR settings will halt execution of the php script; if
>> filemtime($full_name) encounters a "file not found" error, the script
>> stops, and does not execute the subsequent printf() statements.
>>
>>
>> E_WARNING settings will not halt execution of the php script; if
>> filemtime($full_name) encounters a "file not found" error, the script
>> continues and tries execute the subsequent printf() statements.
>>
>> Compare the php.ini settings (both explicit and implicit-default) from
>> both
>> sites, especially the error_reporting and display_errors values, to
>> see how
>> you've set PHP to handle errors.
>>
>> HTH
>>
>
> Indeed. When I do phpinfo on both hosts:
>
> edmullen.net - error_reporting = 22517
> guitarsnotguns.org - error_reporting = 30711
>
> I haven't yet figured out how to get access to the php.ini file on
> DreamHost, GNG's hosting service. Their documentation/help is somewhat
> byzantine.
>
> Thanks, Lew.
>
> P.S. Googled and found that if I put this in the custom error pages as
> the first line in "include" script it stops the error. The date is
> still wrong but that's less annoying.
>
> <?php error_reporting(22517); ?>
>
>
>

If you INSIST on using this footer, good programming requires you to
check for the presence of the file (see file_exists) before calling
filemtime(). If it doesn't exist, don't call filemtime and don't
display the time.

But why even include the footer in you error page?

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
Re: 404 error [message #185646 is a reply to message #185641] Wed, 23 April 2014 19:38 Go to previous messageGo to next message
Christoph Michael Bec is currently offline  Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
Senior Member
Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>
>> Christoph Michael Becker wrote:
>>
>>> Thomas 'PointedEars' Lahn:
>>>> You might be looking for filemtime(__FILE__) instead.
>>>
>>> __FILE__ contains the filepath of the currently *included* file; in Ed's
>>> case the following should be more appropriate:
>>>
>>> filemtime($_SERVER['SCRIPT_NAME']);
>>
>> IBTD. Who is to tell that he did not want the modification time of an
>> include? As it is, the code makes no sense anyway, even with the
>> corrections I suggested.
>
> In <news:7f2rl4(dot)2fb(dot)17(dot)1(at)news(dot)alt(dot)net> Ed Mullen wrote:
>
>> I have two sites on different hosts.
>>
>> Both use identical code to display a "last modified" message. The
>> code is in a standard footer which is included (via PHP) on ever site
>> page.
>
> From that and the rest of the OP I assume, that the requested PHP
> resource (rot.php) is stored as a file, and the last modification date
> of this file should be displayed, what doesn't seem to be unreasonable
> as long as it would be modified regarding the contained HTML, only.

Nonsense. I should have read the OP more carefully in the first place.

Of course, it makes no sense to try to show the last modification time
of an error document, and even less of a non existing resource.

--
Christoph M. Becker
SCRIPT_NAME (was: 404 error) [message #185647 is a reply to message #185639] Wed, 23 April 2014 19:46 Go to previous messageGo to next message
Christoph Michael Bec is currently offline  Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
Senior Member
Jerry Stuckle wrote:

> On 4/23/2014 8:21 AM, Christoph Michael Becker wrote:
>> Thomas 'PointedEars' Lahn:
>>
>>> Look closely at that warning. This approach is not going to work
>>> reliably
>>> because the HTTP request URI does not need to have anything to do
>>> with the
>>> file path of the resource. In fact, there does not even need to be a
>>> real
>>> file for a URI, the served content could have been generated entirely
>>> by PHP
>>> (and usually is). As a result, in those cases filemtime() returns
>>> FALSE …
>>
>> ACK.
>>
>>> You might be looking for filemtime(__FILE__) instead.
>>
>> __FILE__ contains the filepath of the currently *included* file; in Ed's
>> case the following should be more appropriate:
>>
>
> True - which in this case would be the footer, not the requested page.
>
>> filemtime($_SERVER['SCRIPT_NAME']);
>>
>
> Unfortunately, this, too, may or may not have any relationship to the
> file system.

Indeed, you're right. Thanks for pointing that out.

I was mislead by the ambiguous documentation in the PHP manual[1], which
states:

| Contains the current script's path.

The CGI 1.1 specification[2] clarifies this:

| The SCRIPT_NAME variable MUST be set to a URI path (not URL-encoded)
| which could identify the CGI script

[1] <http://www.php.net/manual/en/reserved.variables.server.php>
[2] <https://tools.ietf.org/html/rfc3875#section-4.1.13>

--
Christoph M. Becker
Re: SCRIPT_NAME [message #185648 is a reply to message #185647] Wed, 23 April 2014 20:36 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
On 4/23/2014 3:46 PM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 4/23/2014 8:21 AM, Christoph Michael Becker wrote:
>>> Thomas 'PointedEars' Lahn:
>>>
>>>> Look closely at that warning. This approach is not going to work
>>>> reliably
>>>> because the HTTP request URI does not need to have anything to do
>>>> with the
>>>> file path of the resource. In fact, there does not even need to be a
>>>> real
>>>> file for a URI, the served content could have been generated entirely
>>>> by PHP
>>>> (and usually is). As a result, in those cases filemtime() returns
>>>> FALSE …
>>>
>>> ACK.
>>>
>>>> You might be looking for filemtime(__FILE__) instead.
>>>
>>> __FILE__ contains the filepath of the currently *included* file; in Ed's
>>> case the following should be more appropriate:
>>>
>>
>> True - which in this case would be the footer, not the requested page.
>>
>>> filemtime($_SERVER['SCRIPT_NAME']);
>>>
>>
>> Unfortunately, this, too, may or may not have any relationship to the
>> file system.
>
> Indeed, you're right. Thanks for pointing that out.
>
> I was mislead by the ambiguous documentation in the PHP manual[1], which
> states:
>
> | Contains the current script's path.
>
> The CGI 1.1 specification[2] clarifies this:
>
> | The SCRIPT_NAME variable MUST be set to a URI path (not URL-encoded)
> | which could identify the CGI script
>
> [1] <http://www.php.net/manual/en/reserved.variables.server.php>
> [2] <https://tools.ietf.org/html/rfc3875#section-4.1.13>
>

There are two problems here. The first one comes when you use the
Apache rewrite option to rewrite URIs. This is commonly done with CMS's
where the actual pages are in a database, and one file handles all of
the requests (but is often used in other situations, also). In such a
case, there is no separate file.

The second problem comes in when you use the Alias (or ScriptAlias)
Apache directive to dynamically alter file paths (similar to a Linux
symlink, but on a virtual server by virtual server basis). I use the
latter regularly for images which are common to multiple websites, for
instance. So the request my refer to /images/logo.png, but the real
location is /var/www/images/logo.php (doc root would be
/var/www/sitename/html). And cgi scripts may be in /user/bin/cgi, but
the URL points to /cgi-bin.

Of course, if you don't use any of the above, the file system will
reflect the document root with the URL appended.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
Re: 404 error [message #185649 is a reply to message #185644] Wed, 23 April 2014 21:28 Go to previous messageGo to next message
Denis McMahon is currently offline  Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
Senior Member
On Wed, 23 Apr 2014 14:22:29 -0400, Ed Mullen wrote:

> Tried various things and decided to apply the KISS method. Made a
> separate footer text file for the custom error files without the "last
> modified" code in it.

Actually, the KISS method would be a basic 404.html with nothing in it
that might break if something changes in php, the server config, the
phase of the moon etc.

--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
Re: SCRIPT_NAME [message #185650 is a reply to message #185647] Wed, 23 April 2014 22:27 Go to previous messageGo to next message
Thomas 'PointedEars'  is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
Senior Member
Christoph Michael Becker wrote:

> Jerry Stuckle wrote:
>> On 4/23/2014 8:21 AM, Christoph Michael Becker wrote:
>>> filemtime($_SERVER['SCRIPT_NAME']);
>>>
>>
>> Unfortunately, this, too, may or may not have any relationship to the
>> file system.
>
> Indeed, you're right. Thanks for pointing that out.
>
> I was mislead by the ambiguous documentation in the PHP manual[1], which
> states:
>
> | Contains the current script's path.
>
> The CGI 1.1 specification[2] clarifies this:
>
> | The SCRIPT_NAME variable MUST be set to a URI path (not URL-encoded)
> | which could identify the CGI script

and

| The SCRIPT_NAME string forms some leading part of the path component
| of the Script-URI derived in some implementation-defined manner.

> [1] <http://www.php.net/manual/en/reserved.variables.server.php>
> [2] <https://tools.ietf.org/html/rfc3875#section-4.1.13>

$_SERVER['SCRIPT_NAME'] WFM for forms and links (“action” and “href”
attributes).

$_SERVER['SCRIPT_FILENAME'] WFM for script files.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
Re: 404 error [message #185651 is a reply to message #185645] Thu, 24 April 2014 00:19 Go to previous messageGo to next message
Ed Mullen is currently offline  Ed Mullen
Messages: 11
Registered: January 2014
Karma: 0
Junior Member
Jerry Stuckle wrote:
> On 4/23/2014 1:12 PM, Ed Mullen wrote:
>> Lew Pitcher wrote:
>>> On Tuesday 22 April 2014 13:32, in comp.lang.php, "Ed Mullen"
>>> <ejEVOMER(at)edmullen(dot)net> wrote:
>>>
>>>> Ed Mullen wrote:
>>>> > Jerry Stuckle wrote:
>>>> >> On 4/22/2014 12:41 PM, Ed Mullen wrote:
>>>> >>> I have two sites on different hosts.
>>>> >>>
>>>> >>> Both use identical code to display a "last modified" message. The
>>>> >>> code
>>>> >>> is in a standard footer which is included (via PHP) on ever site
>>>> >>> page.
>>>> >>>
>>>> >>> I just noticed something odd. At my site <http://edmullen.net> it
>>>> >>> works
>>>> >>> just fine. The first link below shows a standard page with the
>>>> >>> footer
>>>> >>> message. The second will produce an error page since the link
>>>> >>> doesn't
>>>> >>> exist on the site. On the error page the date info is simply not
>>>> >>> displayed.
>>>> >>>
>>>> >>> <http://edmullen.net/index.php>
>>>> >>>
>>>> >>> <http://edmullen.net/bogus.php>
>>>> >>>
>>>> >>> Fine so far. The other site has different results.
>>>> >>>
>>>> >>> <http://guitarsnotguns.org/>
>>>> >>>
>>>> >>> <http://guitarsnotguns.org/rot.php>
>>>> >>>
>>>> >>> Notice the error message and incorrect date in the footer.
>>>> >>>
>>>> >>> I'm guessing it's a server configuration issue. Any thoughts?
>>>> >>>
>>>> >>> BTW, here's the PHP I use on both sites:
>>>> >>>
>>>> >>> <?php
>>>> >>> $current_file_name = ($_SERVER['REQUEST_URI']);
>>>> >>> $current_path = ($_SERVER['DOCUMENT_ROOT']);
>>>> >>> $full_name = $current_path.$current_file_name;
>>>> >>> $last_modified = filemtime($full_name);
>>>> >>> print("This page last changed: ");
>>>> >>> print(date("F j, Y - h:i A", $last_modified));
>>>> >>> ?>
>>>> >>>
>>>> >>> Thanks.
>>>> >>>
>>>> >>
>>>> >> If the file doesn't exist, how can you get its time?
>>>> >>
>>>> >
>>>> > Agreed. Not expecting to.
>>>> >
>>>> >> It looks like you're including your footer in the failing page, but
>>>> >> not
>>>> >> in the working one. This is not a PHP issue.
>>>> >>
>>>> >>
>>>> >
>>>> > The footer is in the two good links above. The failing pages above do
>>>> > not exist: They're links to a non-existant file. Hence the 404
>>>> > result.
>>>> >
>>>> > What I'm asking about is how the two hosts' servers handle it. The
>>>> > first displays the custom 404 page WITHOUT showing the date in the
>>>> > footer. No idea why.
>>>> >
>>>> > The second host shows the 404 page but throws an error where the "date
>>>> > modified" info should be. Obviously
>>>> >
>>>>
>>>> Oops. Hit send too fast.
>>>>
>>>> I was going to say that obviously there is something different about
>>>> the
>>>> servers set up.
>>>>
>>>> I agree, it's probably not a PHP issue. Just thought the smart folks
>>>> here might have an idea.
>>>
>>>
>>> My (semi-educated) guess:
>>>
>>> On edmullen.net, your php.ini file sets the error_reporting value to
>>> E_ERROR, while on guitarsnotguns.org, the php.ini file sets the
>>> error_reporting value to E_WARNING
>>>
>>> E_ERROR settings will halt execution of the php script; if
>>> filemtime($full_name) encounters a "file not found" error, the script
>>> stops, and does not execute the subsequent printf() statements.
>>>
>>>
>>> E_WARNING settings will not halt execution of the php script; if
>>> filemtime($full_name) encounters a "file not found" error, the script
>>> continues and tries execute the subsequent printf() statements.
>>>
>>> Compare the php.ini settings (both explicit and implicit-default) from
>>> both
>>> sites, especially the error_reporting and display_errors values, to
>>> see how
>>> you've set PHP to handle errors.
>>>
>>> HTH
>>>
>>
>> Indeed. When I do phpinfo on both hosts:
>>
>> edmullen.net - error_reporting = 22517
>> guitarsnotguns.org - error_reporting = 30711
>>
>> I haven't yet figured out how to get access to the php.ini file on
>> DreamHost, GNG's hosting service. Their documentation/help is somewhat
>> byzantine.
>>
>> Thanks, Lew.
>>
>> P.S. Googled and found that if I put this in the custom error pages as
>> the first line in "include" script it stops the error. The date is
>> still wrong but that's less annoying.
>>
>> <?php error_reporting(22517); ?>
>>
>>
>>
>
> If you INSIST on using this footer, good programming requires you to
> check for the presence of the file (see file_exists) before calling
> filemtime(). If it doesn't exist, don't call filemtime and don't
> display the time.
>
> But why even include the footer in you error page?
>

Indeed, see my other reply in this thread.


--
Ed Mullen
http://edmullen.net/
As I said before, I never repeat myself.
Re: SCRIPT_NAME [message #185653 is a reply to message #185650] Thu, 24 April 2014 22:35 Go to previous message
Christoph Michael Bec is currently offline  Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
Senior Member
Thomas 'PointedEars' Lahn wrote:

> Christoph Michael Becker wrote:
>
>> Jerry Stuckle wrote:
>>> On 4/23/2014 8:21 AM, Christoph Michael Becker wrote:
>>>> filemtime($_SERVER['SCRIPT_NAME']);
>>>>
>>>
>>> Unfortunately, this, too, may or may not have any relationship to the
>>> file system.
>>
>> Indeed, you're right. Thanks for pointing that out.
>>
>> I was mislead by the ambiguous documentation in the PHP manual[1], which
>> states:
>>
>> | Contains the current script's path.
>>
>> The CGI 1.1 specification[2] clarifies this:
>>
>> | The SCRIPT_NAME variable MUST be set to a URI path (not URL-encoded)
>> | which could identify the CGI script
>
> and
>
> | The SCRIPT_NAME string forms some leading part of the path component
> | of the Script-URI derived in some implementation-defined manner.
>
>> [1] <http://www.php.net/manual/en/reserved.variables.server.php>
>> [2] <https://tools.ietf.org/html/rfc3875#section-4.1.13>
>
> $_SERVER['SCRIPT_NAME'] WFM for forms and links (“action” and “href”
> attributes).
>
> $_SERVER['SCRIPT_FILENAME'] WFM for script files.

Thanks for the pointer. I just found $_SERVER['PATH_TRANSLATED'], which
might be even more appropriate, if available. Apparently, these
variables have to be used on a "WFM" basis, as there doesn't seem to be
any "standardized" specification.

--
Christoph M. Becker
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Use PHP to populate a Mailing list from a webpage
Next Topic: Re: Disaster Mitigation Program - Apr. 27, 2014
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Mar 28 19:21:03 GMT 2024

Total time taken to generate the page: 0.02534 seconds