RE: PHP list as a blog

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux