On Wed, 2007-06-13 at 13:13 -0500, Richard Lynch wrote:
>
> I am currently averaging 2 posts per year, roughly, including today's
> rant about header("Location:"):
>
> http://richardlynchblogspot.com
I strongly disagree with your argument for the use of using require
logic instead of a redirect.
> PHP responds over dog-slow Internet with 301 Redirect to login.php.
> Browser interprets 301 Redirect, hopefully correctly.
This is incorrect, PHP sends a 302 status code. From the online docs:
"The second special case is the "Location:" header. Not
only does it send this header back to the browser, but
it also returns a REDIRECT (302) status code to the
browser unless some 3xx status code has already been set."
>From Wikipedia we learn:
"302 Found
This is the most popular redirect code, but also an
example of industrial practice contradicting the standard.
HTTP/1.0 specification (RFC 1945) required the client to
perform a temporary redirect (the original describing
phrase was "Moved Temporarily"), but popular browsers
implemented it as a 303 See Other. Therefore, HTTP/1.1
added status codes 303 and 307 to disambiguate between
the two behaviors. However, majority of Web applications
and frameworks still use the 302 status code as if it
were the 303.
303 See Other (since HTTP/1.1)
The response to the request can be found under another URI
using a GET method."
As such 302 is the best method IMHO since it is industry practiced and
supported back to HTTP/1.0.
> Maybe you should consider just doing this instead:
>
> if( !logged_in() )
> {
> require 'login.php';
> exit;
> }
I strongly disagree with this since it breaks the request/content
linking. For instance if I request:
http://l33t.pr0n.xxx/leatherAndLace.php
And you serve up a login page then I'm sure as hell not getting what I
expected. If something else should happen beyond a login request then
it's possible and VERY likely that search engines, if they can access
the content, will index the WRONG content with the URL. As such it
breaks the link/content relationship and is a bad idea.
Additionally, if there are multiple branches based on some internally
measured variable, then it is possible that parameters should be passed
to the page as would normally be done via the URL. Stuffing them into
$_GET yourself is abusive of the semantic definition of $_GET.
Additionally, users bookmarking your page will not get the same content
next time round if it is dependent on such $_GET variables.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
