404 Support

jdueck · 2005-08-19 03:32:05

Why does txp have to create the error message? Why not just throw a 404 and let ErrorDocument handle it?

thebombsite · 2005-08-19 03:32:44

Does that mean I can try it now? When you say non-customisable does that mean I can’t use my own 404 page?

zem · 2005-08-19 04:05:43

When you say non-customisable does that mean I can’t use my own 404 page?

Yes. It’s just a generic one-liner error message for now (or will be, once the translations are updated).

Why not just throw a 404 and let ErrorDocument handle it?

Because one control has been passed to PHP, there’s no way I’m aware of for PHP to pass it back to the web server and say “here, please handle this as a 404 error”.

Andrew · 2005-08-19 04:44:43

zem wrote: Because one control has been passed to PHP, there’s no way I’m aware of for PHP to pass it back to the web server and say “here, please handle this as a 404 error”.

Wait… that seems strange to me. If that were so, sgb_url_handler and sgb_error_documents wouldn’t work. I’ve always wondered why Txp didn’t use the same method used by many CMS, which is to always start with a (logic) 404 and require that conditions be met with the requested url in order to change it to a 200. And only after everything has been figured out pass the header.

(I’m not trying to teach the teacher here, this has just been something I’ve never bothered digging deep into the txp core about and I’ve always been curious why it’s been so danged hard to implement… maybe this’ll motivate me)

zem · 2005-08-19 05:23:36

the same method used by many CMS, which is to always start with a (logic) 404 and require that conditions be met with the requested url in order to change it to a 200.

Can you give an example please? I’m not sure that we’re talking about the same things. If there’s a logical error in the new 404 handling code, can you describe it please?

It looks to me like sgb_error_documents does the job of fetching a user-configured file and serving it up to the browser. That’s what we’ll do eventually, but probably not in the stable branch, as I say, because it goes well beyond just fixing the bugs caused by the lack of 404 handling.

Andrew · 2005-08-19 06:10:46

Yeah perhaps we’re talking about two separate things, or I’m just confused (not unlikely). I was referring to Txp’s ability to throw a 404 or 301 or whatever header response based on some url parsing logic.

Wordpress, for example, does something like this before any headers are sent:

<pre>
// Process PATH_INFO and 404.
if ((isset($_GET[‘error’]) && $_GET[‘error’] '404') || ((! empty($_SERVER['PATH_INFO'])) && ('/' != $_SERVER['PATH_INFO']) && (false = strpos($_SERVER[‘PATH_INFO’], ‘.php’)) )) {

// If we match a rewrite rule, this will be cleared. $error = ‘404’;

// Fetch the rewrite rules. $rewrite = $wp_rewrite->wp_rewrite_rules();

[…]

// Sending HTTP headers

if ( !empty($error) && ‘404’ == $error ) { if ( preg_match(‘/cgi/’, php_sapi_name()) ) header('Status: 404 Not Found'); elseheader(‘HTTP/1.x 404 Not Found’);

[…]
</pre>

So it checks your request against the site’s set of rewrite rules; if no match, the logic 404 remains and you’re served a 404 header response.

I don’t have a code example from Movable Type, but I seem to remember a similar setup when using the php bootstrapper, although I think what MT does (and it made things a bit complicated) is maintain a separate table altogether storing all the valid urls for the site. If your request doesn’t map across something from that table, the default 404 logic state is not overridden and you are then served a 404 header response rather than a page.

However, I’d have to say that both these solutions have always seemed a bit bloated to me. I’m not a fan of WP’s massive set of rewrite rules; nor was I a fan of an entire table dedicated to storing all the links that may exist for a site at any moment.

colak · 2005-08-19 07:07:07

2 points and a question
1. Great news for the start of error handling
2. I would love for the error to have a link on the root of the site so instead of the “not_found” message we could get something like
“not_found please view the site <code><txp:link_to_home>Here</txp:link_to_home></code>”

Question
Further to my feature request posted <a href=“http://forum.textpattern.com/viewtopic.php?id=10420”>here</a>, I am wondering whether a 404 or a 410 error is the most appropriate one re textpattern.

Last edited by colak (2005-08-19 07:07:53)

Sencer · 2005-08-19 09:10:06

@colak: That’s a feature request, where I really don’t see the necessity to cram it into the 4.0.x line.

@Andrew: Two things – WP has dozens of lines of rewrite rules which only match some of all the incoming requests – unlike our mod_rewrite rules, which match everything that doesn’t exist and let textpattern handle it. If you see a 404 Error Page as defined by the webserver with WP, it is likely because the rewrite rules didn’t match it and the php script never got to see that request.

PHP send exactly one HTTP Status Header – the last one you set in the script. So it doesn’t mattter at all, what you start out with and how you change it. If TXP would only send the header and no body – which is of course possible – then the user would see simply a blank page. AFAIK (and as zem said), it is not possible for PHP to say “Here webserver, I changed my mind, do what you would do with a normal 404”.

If I am wrong and that is possible, then of course I’d like to learn about it. :)

wet · 2005-08-19 11:18:21

> Sencer wrote:

> @colak: That’s a feature request, where I really don’t see the necessity to cram it into the 4.0.x line.

I may sound a little blatant, but I beg to differ:

A thing I would call a feature would be that textpattern reinstantiated the semantics of ErrorDocument existing in Apache when we had file based websites by applying its own method of assigning repository items (forms, pages, sections, search results, a user-provided hook/plugin, whatever design may evolve as useful) to react upon error conditions like 403, 404, eventually 410, 500.

I would not dare to present that meager sentence “You have reached the end of the internet as far as I know of…” to a visitor/client on my website just because she used an outdated bookmark or followed a seasoned google link.

There are some very clever and truthful essays on the net on catching your visitor when your site fails (and its always your site that’s failing, not the visitor or google). None of those suggests to tell your client “Walk away. Nothing here.”

What is done now, is error reporting for the technically inclined. Not error handling.

My 2c.

//w&

zem · 2005-08-19 12:07:04

I would not dare to present that meager sentence “You have reached the end of the internet as far as I know of…” to a visitor/client on my website

Trouble is, we’re not dealing with vistors on a web site. We’re dealing with visitors on thousands of web sites, each of which is running in a different environment, some with only subtle differences, others entirely different platforms. And everyone has a different idea of what should be on that error page.

Baby steps. The previous behaviour – serving up the front page of your web site when someone requested /robots.txt or /favicon.ico or /some/nonexistent/path – was a big problem, and it’s fixed now.

Andrew · 2005-08-19 15:10:00

Edit: thanks zem… ‘sheesh’ is right. When will that Andrew guy shut the hell up? ;-)

Last edited by Andrew (2005-08-19 16:26:48)

wet · 2005-08-19 16:10:08

zem wrote:

Trouble is, we’re not dealing with vistors on a web site. We’re dealing with visitors on thousands of web sites, each of which is running in a different environment, some with only subtle differences, others entirely different platforms. And everyone has a different idea of what should be on that error page.

I wrote:

…reinstantiated the semantics of ErrorDocument existing in Apache when we had file based websites by applying its own method of assigning repository items (forms, pages, sections, search results, a user-provided hook/plugin, whatever design may evolve as useful)…

So from my point of view we both agree: Textpattern should provide a means for a user selectable — let me call it — ErrorDocument for a number of well defined error conditions (403, 404 at least), and maybe provide a sample implementation along the lines of todays sample page templates: Its there after an initial seup, it works, and everybody’s free to “bend it, shake it anyway she wants it…” People know their sites, their visitors. I do not expect that textpattern gave me the perfectly layouted page for 404s, but txp should give me the tools. The rest should be a matter of creativity just like today all of txp’s users are creative with their page templates, forms and — if they are coders — with their plug-ins.

Assuming that the database is still ok (which I hope it is when encountering a 403 or 404 condition) textpattern could lay all responsibility into the hands of the site owners if it only defined the rules / API /conventions or whatever you’d like to call it. This rules could be as dumb as “every 404 condition is handled by rendering article with $id=911” or as complicated as “we will call a function you could name on the admin side, passing in the following parameters: … and expect it to return the ROT13-encoded URL of …” You know what I mean…

And I am glad I would not have to code this ;)

//w&

Last edited by wet (2005-08-19 19:04:01)

Sencer · 2005-08-19 17:19:41

> wet wrote:
> I may sound a little blatant, but I beg to differ:

Not really (at least not in what you wrote). colak was asking about 410 for deleted articles. And that would be in line what you call a feature request as well (your’s being more elaborate and certainly something to look for down the line).

A 404 and a 200 are important differences to clients, especially search engines. It’s the difference between a page appearing in search results and not appearing there, with respect to duplicate pages, certainly something that’s relevant.

The difference between a 404 and 410 is mostly semantic, and I while, too, like the idea, in the real world I don’t know of any client that will behave differently for a 410 than it would for a 404.

Oh, and when looking for Feature requests, I am sure this thread is not going to be the place where we would think of looking, so they really are better off in a different place. ;)

wet · 2005-08-19 19:02:03

> Sencer wrote:

Not really (at least not in what you wrote). colak was asking about 410 for deleted articles. And that would be in line what you call a feature request as well…

Agree, I’ve mixed a few things up as I was responding with respect to colak writing this:

2. I would love for the error to have a link on the root of the site so instead of the “not_found” message we could get something like “not_found please view the site <txp:link_to_home>Here</txp:link_to_home>”

which was what I thought you’d call a feature request, especially when obeying this thread’s topic. I personally wouldn’t need any 410 handling in the near future, as I do not expect to have much use for it… And I wouldn’t like neither Txp nor myself to care for all the bookkeeping overhead with respect to articles, images, files, anchor segments and even comments. ymmv.

//w&

zem · 2005-08-19 23:50:58

‘sheesh’ is right. When will that Andrew guy shut the hell up? ;-)

The ‘sheesh’ was aimed at me. It only took me, what, like eight thousand checkins to get a simple 404 message right? :)

Nothing is as simple as it sounds, even things that really are simple. Which is precisely why:

Textpattern should provide a means for a user selectable—let me call it—ErrorDocument for a number of well defined error conditions (403, 404 at least) [..etc..]

..will come later. I’ve written and re-written Textpattern errordoc handling enough times to know there are many things that can go wrong, and many different interpretations of what should happen and what should be possible. Error handling is a critical function: what happens if an error happens while you’re trying to handle an error? How do we localize it? The first step is a basic failsafe error message display, which is what we have now.

Other things will come later, and they’ll come one step at a time. Textpattern has been a continual source of education to all of us on the dev team. Any developer deals with Murphy’s Law every day. But it’s not until you sit in the hot seat that you realise just how ruthlessly efficient a large distributed user base is at proving it. Every mistake or assumption we make is multiplied several thousand-fold, over all of the sites running Textpattern, on a range of different and sometimes incompatible platforms and environments, and many times over again, for every visitor to every one of those sites.

So I’ll hope you’ll forgive us for stepping slowly and carefully in the stable branch.

Textpattern CMS

Textpattern CMS support forum

#16 2005-08-19 03:32:05

Re: 404 Support

#17 2005-08-19 03:32:44

Re: 404 Support

#18 2005-08-19 04:05:43

Re: 404 Support

#19 2005-08-19 04:44:43

Re: 404 Support

#20 2005-08-19 05:23:36

Re: 404 Support

#21 2005-08-19 06:10:46

Re: 404 Support

#22 2005-08-19 07:07:07

Re: 404 Support

#23 2005-08-19 09:10:06

Re: 404 Support

#24 2005-08-19 11:18:21

Re: 404 Support

#25 2005-08-19 12:07:04

Re: 404 Support

#26 2005-08-19 15:10:00

Re: 404 Support

#27 2005-08-19 16:10:08

Re: 404 Support

#28 2005-08-19 17:19:41

Re: 404 Support

#29 2005-08-19 19:02:03

Re: 404 Support

#30 2005-08-19 23:50:58

Re: 404 Support

Board footer