Wandering Thoughts archives

Where to find specifications on HTTP POST behavior

Some IP addresses (probably not friendly ones) have recently taken to making 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 will accept.

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 POST is unambiguously allowed by the HTTP specification, so the only question is whether you are allowed to do it specifically in HTTP form POSTs.)

The primary specification of form POST behavior is in the HTML 4.01 specification, 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 enctype attribute. 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 charset parameter on the POST's Content-Type.

(Browsers are encouraged to interpret a missing accept-charset as 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 anyways.

• 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_html subdirectory, 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.