Where to find specifications on HTTP POST behavior
Some IP addresses (probably not friendly ones) have recently taken to
POST submissions to various 'write comments' URLs here with
a Content-Type of 'application/x-www-form-urlencoded; charset=UTF-8'.
These get rejected by DWiki, because I was quite paranoid when I wrote
the POST handling code and so DWiki is quite conservative on what it
While I was pretty certain that I wasn't losing anything by rejecting
these requests, I did get curious to find out if adding a character
set to a form
POST content-type this way is actually legal, which
meant that I wanted to run down where this is actually specified.
(In general including a charset in the content-type on
unambiguously allowed by the HTTP specification, so the only question is
whether you are allowed to do it specifically in HTTP form
The primary specification of form POST behavior is in the HTML 4.01
which should not have surprised me but did (I looked at the HTTP spec
first). Section 17.13.3 describes the process of submitting a form, but
you also need 17.13.4 and the definition of the
Unfortunately this doesn't clearly answer the question, since the
specification uses very general language.
However, I think that adding a charset parameter has to be allowed by
implication. Forms may specify that the server can accept more than
one character encoding and leave it up to the client to decide which
one to use (the
accept-charset <form> attribute). This implies that
the client must tell the server which character set it picked, and the
form encoding rules provide no place to put this except as a
parameter on the
(Browsers are encouraged to interpret a missing
implying the character set of the HTML page with the form, which is
UTF-8 in the case of WanderingThoughts. However, including a charset
at all in this case is vanishingly rare.)
I'm still not going to fix DWiki's code right away, since I want to think through what I can and should do if the character set doesn't match. (Bearing in mind that my tolerance for people playing weird HTTP and HTML games is fairly low, since most of them are up to no good.)
Features that I wish ZFS had
This is not counting features that Sun has already said they are going to put in someday, like the ability to remove vdevs from a ZFS pool. The motivation for many of these wishes is good long term storage management, something that ZFS is currently weak at.
- the ability to migrate a filesystem from storage pool to storage
pool (on the same system) without user-visible downtime or lockups.
In theory this ought to be doable, since ZFS is abstracting everything
- the ability to control and change what vdevs a filesystem will use
(or occupy), or at least what sort of vdevs they will or won't
use. This would make it easier to have filesystems with different
levels of reliability needs in the same general storage pool,
especially when those needs change.
(To a certain extent this isn't needed if there is transparent storage pool to storage pool migration of filesystems.)
- the ability to turn an existing directory into a sub-filesystem,
or an existing sub-filesystem back into an ordinary directory,
without losing the contents in either case.
An example may help illustrate why I want this. The natural grouping of people's home directories around here is by group; everyone in one group gets clumped into one top-level directory. However, every so often a professor will want to do something like NFS-export their home directory to their personal workstation.
The theoretical ZFS answer is to make everyone's home directory into a ZFS filesystem right up front. However, this leads to a profusion of NFS mounts; it would be nicer if we could defer turning someone's home directory into a filesystem until we really needed to.
- an option so that if you NFS mount a given ZFS filesystem, you
automatically get all of the sub-filesystems that you have NFS
access permission for without having to mount them explicitly.
The problem with using ZFS the way that Sun wants you to in an NFS world is that you wind up with thousands of NFS mounts in even a modest environment. But this is hard to manage, especially when you create and delete filesystem-worthy entities all the time. Many of these entities will have the same NFS export permissions; they are being created for other things, like quota control or separate snapshots or so on. It would be nice to be able to treat them as a unit, so you could mount the top level filesystem and didn't have to care about the details of all of the sub-filesystems.
(For example, we should really have one ZFS filesystem per user home directory, and another ZFS filesystem for their
public_htmlsubdirectory, so that we can export it to the web server but deny the web server general home directory permissions, and things proliferate from there.)
Disclaimer: to the best of my knowledge, ZFS doesn't have and isn't planned to have these features; however, I would be happy to be wrong.