On Wed, 2007-06-13 at 14:36 -0500, Richard Lynch wrote: > On Wed, June 13, 2007 2:08 pm, Robert Cummings wrote: > > On Wed, 2007-06-13 at 13:13 -0500, Richard Lynch wrote: > > 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: > > You're right, of course, as a 301 would be a permanent redirect, and > PHP doesn't "know" if you moved your content permanently or > temporarily, so 302 (temporary) is the safe answer... Or it's the statistically safe bet since it's more likely your content didn't move and that you're just doing a temporary redirect. > > "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." > > You're still sending the response to the browser, then the browser has > to interpret it, then the browser has to request the new URL, chewing > up another HTTP connection resource, and bogging down your server, > before PHP can be invoked a second time, to do an include > 'login.php'... > > Or you could just include 'login.php' in the first place, and SKIP ALL > THAT CRAP. The extra request is not a good excuse for breaking the semantic linking of the web. I didn't request login.php, I requested leatherAndLace.php and so I want leather and lace or you better tell me I'm on the wrong page. It's like walking into a bar, requesting a pint of Guinness and the bartender say, sorry I haven't checked your ID, but to save myself a trip I'll just give you a Shirley Temple... you sould be fine with that right? HELL NO!! I want my Guinness! :) > >>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. > > IE is the one that chose to mis-interpret a POST with a 302 response > with an incomplete URI as a 303. 303 didn't exist in HTTP/1.0, you have to do something. 302 was a close enough match in HTTP/1.0 and HTTP/1.1 that it became the industry standard regardless of what Microsoft did. > *HOW* MS managed to code that badly is beyond my ken, but there it is. > > I alluded to this in my blog. > > > As such 302 is the best method IMHO since it is industry practiced and > > supported back to HTTP/1.0. > > I don't really care which 30x code you use -- You're STILL bouncing > the user like a white ferret [*] instead of just doing the 'include' > you're going to need to do in the end. I'm bouncing them around because I'm the incorrect source for the information they a requesting. There is a proper chain of command to be followed. First they must log in. If a user just registered on my website via http://foo.fee.com/register.php and they complete the registration and I just go ahead and include news.php how is that semantically valid? No, I redirect them to news.php so they can bookmark it if it happens to interest them. > > 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. > > If you're silly enough to hard-code the response "now" of a dynamic > page as if it were the one and only response ever, then you've got > much bigger problems than a silly login form... If you're short-sighted enough to serve up mismatched content with the actual request then you deserve the soup of Bookmarked links that point to incorrect pages that your users create. > > 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. > > I have NO IDEA what heck you are talking about with stuffing values > into $_GET variables, unless, of course, you refer to people who do: > > header("Location: example.com?foo=$_GET[foo]"); No, you have a set of variables for the content the user REQUESTED, not for the content you've arbitrarily decided to haphazardously mish-mashedly serve to them instead because you wanted to save yourself a request. > and expect it to work... No, I would use an absolute URL for the redirect. I'm quite aware of the RFC for redirect URIs. > Whereas I'm suggesting that you already HAVE your $_GET data, and you > already KNOW what content to server up for *THIS* request, and you > should just serve up the content you're supposed to serve up and be > done with it. But you might not. It depends on what you decide to include() instead of redirecting. I guess in the included source you could code aorund not having the correct URL parameters and default to something sensible, but that still doesn't address the content/request mismatch. 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
