But that's not valid HTML post-3.whatever.

Yeah, if you specify the DTD at the top of the page, it won't allow ANY height tags in the page. It will allow height styles, though, but that produces what we've been discussing.

Also, I've found that if I try to mix width tags with width styles, I get unusual results. So, pretty much the only tags I have in my tables are class, cellspacing, and cellpadding. Why they didn't add those last two to CSS is beyond me. Seems hypocritical to me, to demand the use of styles for some things and just ignore others.

But that's not valid HTML post-3.whatever.

Why? Because it LACKS the WIDTH tag, or some other reason?

(Only asking for curiosity sake. I use that alla time, and have yet to have a problem on any of the 'common' browsers..)

Me.

Sorry. I completely missed that until i went back to look at the examples. Yeah, CSS w/h and tag w/h really mess things up. I have pulled alot of hair out trying to get things to lay out properly. (My beef was with WIDTH, and had numerous problems, where IE would do as expected, but then Opera/Mozilla would be 'short', then fix it, and IE would be too far right..) Unfortunately, since many, many people *USE* IE, you can't just say, 'screw Macrosoft..' and do it the way you want.. (Well, at least, you can't when you do commercial sites, like the one I'm workign on..)

Me..

Because height, amongst, I'm sure, other attributes, is deprecated in HTML 4 and greater, including XHTML.

So, basically, in HTML 4, they're moving everything to stylesheets? Interesting..
Thanks!
Me.

amongst, I'm sure, other attributes

Yup, plenty. I understand the idea, but anyone here could do it better than they are now. I haven't a clue what the W3C thinks they're doing. There seems to be no rhyme or reason as to how they decide to move to new standards.

I also like how many of the sites I see are talking about conforming to the standards, but they use the <font> tag, which I thought wasn't allowed.

I agree. I think it's stupid to deprecate all the tags' attributes so that you can reintegrate them within the style attribute. Have the browsers do half an iota of work and understand the regular attributes, too, and internally convert them to style-type information. It's just making things more difficult for HTML writers.

default to something like home.php.

I've been playing with something like this a little. I have an some other questions:

What if I want to return a 404 instead? How do I raise a 404 response error in PHP?

More specifically, I've got a bit of code like this:

<? 

if (file_exists($f)) {

    output_header();

    include($f);

    output_footer();

}

else {

    header('HTTP/1.0 404 Not Found');

}

...which works, but I'd like to raise the 404 error in such a way that Apache serves my ErrorDocument. Is this possible?

Oh, and a security question: currently, this allows access outside the webserver's directories (you can use /index.php?f=/etc/passwd for example). Any good tips on avoiding this kind of problem?

<?php 

if (file_exists($f)) {

    output_header();

    include($f);

    output_footer();

}

else {

    require("YourApacheErrorDocument.html");

} 

?>

require("YourApacheErrorDocument.html");

So you're saying that there's no way I can "raise an exception" from the PHP file to cause Apache to forget everything and treat it as a 404, then?

Nope, but that will accomplish the same thing. I would guess, however, that by the time you are processing the PHP file, Apache has determined that the target file exists, and can merely send back the result from the PHP file.

I've seen some references to throwing an

exit;

right after the header() making it do the right thing, but it doesn't work on my installation, which is admittedly quite old. You might want to give it a shot. Of course, make sure that it's the first piece of data you send.

Oh, and a security question: currently, this allows access outside the webserver's directories (you can use /index.php?f=/etc/passwd for example). Any good tips on avoiding this kind of problem?


I don't get this problem, probably down to the server configuration, but I've put a simple preg in place to remove anything that isn't alphanumeric, just in case.

$f=preg_replace('/[^0-9A-Za-z]/', '', $f); 

probably down to the server configuration

Are you running your server chroot-ed? There's nothing in my configuration that'd stop the www-data user from accessing stuff outside /var/www (and it has to run like that -- some things shouldn't be in the public webspace, but ought to be accessible to the webserver user).

Four options occur to me:

1. Turn the path given into a fully-qualified path and then check that it's a child directory of the path containing the PHP script. This assumes that I want to allow the illusion of subdirectories.

2. Alternatively, I could use a regex to turn slashes into underscores, e.g. and then disallow any other directory traversal.

3. Turn the file access into another HTTP access and allow the webserver to deal with it. Not a great idea from a usage point of view.

4. Stuff the content into a database.

I think I'll probably go with option 1 for this website. I want to keep the content in CVS, rather than in a database (the database means I'll need some kind of editing screen as well, which is a pain).