Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #13421 > unrolled thread

404 error

Back to article view | Back to comp.lang.php

Contents

  404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-22 12:41 -0400
    Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-22 12:58 -0400
      Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-22 13:25 -0400
        Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-22 13:32 -0400
          Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-22 14:35 -0400
          Re: 404 error Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-04-22 14:42 -0400
            Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-22 14:56 -0400
              Re: 404 error Anders Wegge Keller <wegge@wegge.dk> - 2014-04-23 08:56 +0200
                Re: 404 error Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-23 13:12 +0200
                  Re: 404 error Anders Wegge Keller <wegge@wegge.dk> - 2014-04-23 13:23 +0200
                    Re: 404 error Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-23 13:36 +0200
                    Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-23 08:09 -0400
                Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-23 08:08 -0400
            Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-23 13:12 -0400
              Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-23 14:50 -0400
                Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-23 20:19 -0400
    Re: 404 error Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-22 23:26 +0200
      Re: 404 error Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-23 14:21 +0200
        Re: 404 error Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-23 09:12 -0400
          SCRIPT_NAME (was: 404 error) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-23 21:46 +0200
            Re: SCRIPT_NAME Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-23 16:36 -0400
            Re: SCRIPT_NAME Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-24 00:27 +0200
              Re: SCRIPT_NAME Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-25 00:35 +0200
        Re: 404 error Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-23 15:56 +0200
          Re: 404 error Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-23 18:00 +0200
            Re: 404 error Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-23 21:38 +0200
    Re: 404 error Doug Miller <doug_at_milmac_dot_com@example.com> - 2014-04-22 22:04 +0000
      Re: 404 error The Natural Philosopher <tnp@invalid.invalid> - 2014-04-23 00:11 +0100
      Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-22 20:22 -0400
    Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-23 12:39 -0400
      Re: 404 error Ed Mullen <ejEVOMER@edmullen.net> - 2014-04-23 14:22 -0400
        Re: 404 error Denis McMahon <denismfmcmahon@gmail.com> - 2014-04-23 21:28 +0000

Page 2 of 2 — ← Prev page 1 [2]

#13455 — Re: SCRIPT_NAME

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13457 — Re: SCRIPT_NAME

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.)

[toc] | [prev] | [next] | [standalone]

#13460 — Re: SCRIPT_NAME

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

[toc] | [prev] | [next] | [standalone]

#13447

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@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#13448

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.2fb.17.1@news.alt.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

[toc] | [prev] | [next] | [standalone]

#13453

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.2fb.17.1@news.alt.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

[toc] | [prev] | [next] | [standalone]

#13433

Ed Mullen <ejEVOMER@edmullen.net> wrote in news:7f2rl4.2fb.17.1@news.alt.net:

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

What in the world are "guitar snot guns" ?

[toc] | [prev] | [next] | [standalone]

#13434

On 22/04/14 23:04, Doug Miller wrote:
> Ed Mullen <ejEVOMER@edmullen.net> wrote in news:7f2rl4.2fb.17.1@news.alt.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.

[toc] | [prev] | [next] | [standalone]

#13437

Doug Miller wrote:
> Ed Mullen <ejEVOMER@edmullen.net> wrote in news:7f2rl4.2fb.17.1@news.alt.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.

[toc] | [prev] | [next] | [standalone]

#13449

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?

[toc] | [prev] | [next] | [standalone]

#13451

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)?

[toc] | [prev] | [next] | [standalone]

#13456

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@gmail.com

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.php

csiph-web