404 Support

zem · 2005-08-18 22:51:18

Just adding to Sencer’s helpful comments:

The ‘stable’ branch is where we check in changes intended for upcoming stable releases. It doesn’t mean every checkin that goes there is release quality. It will be tested, and won’t contain any of the new features¹, design changes and other risky things going on in the development branch. But there’s a big difference between ‘tested’ and ‘works perfectly’.

(In this case, I cleverly tested every case, for every permlink type, forgetting the obvious /section/ links)

Essentially, by opening svn access to the public, we’re letting everyone join the development process. The /stable branch is what the Development Team would send to the Test Team, if Textpattern was the kind of project built by 9-to-5ers in offices with headset-wearing project managers, name plaques and conservative carpets, Monday morning meetings with instant coffee and cheap donuts, and Powerpoint presentations on the meeting room wall. It’s not.

So, if you’d like to join the Test Team, track the stable branch with Subversion, and help us find the bugs we’ve missed. You’ll probably want to use a separate test site.

If it’s release quality you’re after, stick with the releases.

If you’re brave, foolish, or a developer yourself, you’ll probably want to follow the development branch.

¹ Sometimes the line between ‘bug’ and ‘feature’ isn’t always clear. Is 404 handling a new feature, or is the lack of it a bug? We considered it a bug right from the start, which is why it’s going into the stable branch. It didn’t make it into 4.0 for lack of time.

greenrift · 2005-08-19 00:55:14

Might it be possible to have a “release” branch of SVN. Well, there is already, but I mean one URL that I can point my SVN-stick at and download the latest official “release”, and this URL won’t change?

zem · 2005-08-19 01:40:05

Well, there is already, but I mean one URL that I can point my SVN-stick at and download the latest official “release”, and this URL won’t change?

We’re looking into it.

btw: r817 in /stable restores basic 404 support. (and, before someone asks: no, we’re probably not going to add customizable 404 messages in 4.0.x; that’s getting into new feature territory)

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&

Textpattern CMS

Textpattern CMS support forum

#13 2005-08-18 22:51:18

Re: 404 Support

#14 2005-08-19 00:55:14

Re: 404 Support

#15 2005-08-19 01:40:05

Re: 404 Support

#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

Board footer