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
what most programs try to get is
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.)