Redirect versus refresh

[jbailey]

I spent the weekend cleaning up my vanity site, CSSizing it and such. Since I moved a few documents around, I wanted to make sure that they were still findable. Most of the site wasn't PHP before (it is now for common navigation / footer includes, etc.) so I had the challenge of how to send people to the new pages.

It's most common to find "refresh" pages, ones that you go and they redirect you to another location with a 0 timeout (and often a cute little notice that says if your browser doesn't DTRT, you should click the link). There doesn't seem to be another meta tag that could do the redirect trivially.

This is another case where PHP wound up being useful. Since I moved my weblog from my homesite to LiveJournal a while ago to let comment spam be Someone Else's Problem, I had that and a whole directory of stuff underneath it that was no longer there.

jbailey@titanium:~/web$ cat weblog.php
<?php
header("HTTP/1.0 301 Document Moved");
header("Location: http://jbailey.livejournal.com/");
exit();
?>

Now works for http://www.raspberryginger.com/jbailey/weblog and any of the directories underneath it. Another side trick to this is that if I had a file foo.html, I can create a foo.html.php file with the same sort of thing in it. Apache's automatic extension tracking will find the .php file and sort it out automatically.

One thing I did discover is that if I have "weblog.tar.gz" and "weblog.php" sitting side by side, apache will prefer the .tar.gz file. *sigh*

Comments

content negotiation

[wouterverhelst.livejournal.com]

One thing I did discover is that if I have "weblog.tar.gz" and "weblog.php" sitting side by side, apache will prefer the .tar.gz file. *sigh*

That's configurable (http://www.grep.be/blog/en/computer/play/apache_content_neg)

Re: content negotiation

[(Anonymous)]

If your webhost supports .htaccess files, you may be able to use the Apache "Redirect permanent" and "RedirectMatch permanent" directives. These are less fragile to content-negotiation bugs and configuration changes, plus, you can keep all your redirections in one file, which makes them easier to manage than a sprawl of php files. I also find it "feels" wrong to have files sitting around that aren't "real", but just redirect. Finally, make sure you don't accidentally have a space or any other content in the file prior to the <?php header, or the redirect might not work (depending on if you have output buffering on). Oh, the joy of subtle php misconfigurations...

Re: content negotiation

[jbailey.livejournal.com]

Yeah. In this case, I happen to have root on this webhost, but I'm playing with different options of what I'd use in the event that I didn't. The default setup on this one is that .htaccess files are disabled.

I'm not sure where I am on the "old files lying around" versus just having them in an htaccess file. I tend to like seeing them on a directory.

Re: content negotiation

[jbailey.livejournal.com]

Nice, thanks. =)

[malpingu.livejournal.com]

Nice look! However, I don't like the way the menu 'tabs' will link directly off-site. You might want to position these elsewhere, or use a different background colour or icon to denote an external link.


... But PHP is EVIL.

It's not the language per se that I object to, rather it's the packaging. Of course, other readers will tell you that is configurable, too. Yet, that's exactly why it is EVIL -- it is typically deployed with an insecure default configuration. Sure, there are lots of guides on how to make it secure, but I can't be bothered with it when there are plenty of other solutions that are better suited to the job.

Moreover, another chief complaint is that PHP applications are typically written by amateur programmers (often erstwhile web designers) who have no solid grounding in software engineering, let alone information security (my field of interest), unlike the typical Java or Python programmer.

Nevertheless, as you said, it's simply a vanity page so no worries.
Just thought I'd share an opinion. ;-)

[jbailey.livejournal.com]

PHP's less evil than it could be. Other than Java, the other programming languages don't have any sort of security model at all.

I haven't played with PHP5, but from what I've read, the object model is even sane for doing modern-styles of programming.

[malpingu.livejournal.com]

Oh, I agree. It's not the language per se but rather the way it is usually deployed and used by people unaware of security matters.

For instance, the configuration files for web applications are often left publicly read-/writeable within the application webspace, for ease of administration at many hosting sites. Python applications, on the other hand, are typically deployed as programs invoked ether by a web-server module or CGI interface, in which neither the program image (source or executable) itself nor its configuration files are publicly accessbile.