2005-06-11
Writing DWiki has been a very educational process. Mostly it has been educational about all sorts of irritations that I was previously happily ignorant of.
Take HTTP redirects, for example. (Please.)
To be fully specification-compliant, an HTTP redirect must be to a different URL than the current one, and must be to an absolute URL: it must redirect to http://host/some/where, not just /some/where. (Perhaps common browsers all accept relative redirects, but at least lynx complains about them.)
issue #1: when absolute URLs can't be
This presents a small problem for a program like DWiki: just what is the absolute URL of a DWiki page? The host is relatively easy, since modern HTTP requests include the host name (it's how name-based virtual hosts work).
But ... what about the port? Not every web server lives on port 80, especially a DWiki running in standalone test mode.
In theory the absolute URL should include the port (unless it's the
default). In practice, every program I've tried gleefully adds the port
itself if it is a non-standard port and you're referring to the same
hostname. If you naievely generate redirects of http://host:port/...,
what most programs try to get is http://host:port:port/..., which
doesn't work too well.
Presumably people who want to run two web servers on the same host on different ports just lose.
Maybe this is even documented somewhere. (I jest; I looked, and failed to find anything obvious in the RFCs.)
Update, much later: I was completely mistaken here; see HostMistake.
issue #2: did you say different URL?
Why, yes. Different URL. Why is this irritating? Let's take logging in to this wiki as an example.
Login forms need to be POST forms, not GETs, because one does not want the password sitting in plaintext in URLs. The natural way to do it is to let the login form POST to the current page, which then just redisplays itself. Unfortunately if you then ask your browser to reload the resulting page (perhaps to see an updated edit of it), your browser warns you that you're about to resubmit a POST form and are you sure?
So: what we want to happen is to POST to the current URL, which instead of redisplaying itself in a POST context immediately redirects back to the GET version of itself.
Which is where it becomes very irritating that HTTP redirects have to go to a different URL.
DWiki 'solves' this issue by making up synthetic page names for processing logins (and logouts, which have the same problem). Fortunately it can guarantee that certain page names in its URL space will never be valid real DWiki pages, so it just uses some of them.
To get back to the page you were just reading, the login and logout forms add a hidden field to the form to say what the old page was. (Which means that the form has to be generated dynamically, because it's different on each page.)
I find myself quite irritated with CSS lately, because I have been trying to be a good modern web-boy and style this place with CSS.
The problem with CSS is what it leaves out. Take a very simple example: this blog. Like many blogs, I want a two-column layout: blog entries on the left, a small sidebar about the blog on the right.
No problem in CSS: use two <div>s, set a width: or a min-width:, and
then set one <div> as float: left; or so. And this works, as long as
neither column overflows. Unfortunately, a) I am guaranteed to someday
write a blog entry with a long unbreakable line, since I am going to
quote code periodically and b) the user can make their browser window
pretty darn narrow.
What I want to happen in this situation is for CSS to shrug and enlarge the whole thing so that the user has to scroll sideways to see the entire page. What I can get is one of:
- the over-long line is truncated and is undisplayable.
- the thing containing the over-long line is truncated but grows a scrollbar, so at least I can theoretically read it.
- the over-long line scribbles itself all over the sidebar.
- my sidebar stops being a sidebar and suddenly becomes a top-bar or a bottom-bar.
No, blech, ptui, and 'ha, you jest' respectively.
Those evil bad table things that we aren't supposed to use for layout? Surprise. They get this right.
So if you look at the HTML source for the blog, you will see a giant table.
(Now, perhaps there is some magic way to do this in CSS that actually works right and that no one mentions or uses. If so, please tell me about it. I would like to use CSS if I can.)