Re: PHP list as a blog

Robert Cummings wrote:

On Wed, 2007-06-13 at 13:13 -0500, Richard Lynch wrote:

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

Indeed, this is correct.

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.

Not entirely. 301 and 302 responses are both equally valid but mean subtly different things. A 302 is a temporary redirect. Essentially it tells the client to load a different resource but nothing more than that. A 301 is a permanent redirect. This tells the client to load a different resource, and that any time that original URL is requested it will be redirected. Essentially this means bookmarks and indexes should be modified to point to the new URL.

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.

Completely agree with this, but there are lots of reasons to include files rather than bouncing off the client with a new URL, login requirements is just one example where a redirect would be preferred. -Stut