On Wed, 2007-06-13 at 20:37 +0100, Stut wrote:
> 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.
Yep, I understand that, but the usage example Richard mentioned is
primarily where developers redirect to an alternate location given that
they didn't set the response code themself and relied on PHP's default.
> >> 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.
IMHO an include is preferrable if the content being displayed makes
sense in the context of the URL requested.
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
