v0.1.10

Fixed

• A form was always sent as UTF-8, whatever encoding said. RFC-0001 section 3.6 requires the opposite — values in form are encoded with the source's encoding before percent-encoding — and a site serving a legacy encoding expects its search terms in it. Nothing failed: measured against a GBK host, the search endpoint answered 1,336 bytes and no rows for a UTF-8 body and 3,954 bytes with the novel for the same query as GBK, so the stage returned an empty result rather than an error. A query the named encoding cannot spell, or a codec that does not exist, falls back to the old behaviour rather than failing a stage the caller can still use. The request body changes, so a recorded search on a source that declares a non-UTF-8 encoding has to be re-recorded.