W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: #227: Encoding advice for new headers and parameters

From: Willy Tarreau <w@1wt.eu>
Date: Sat, 1 Oct 2016 08:26:32 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20161001062632.GB31660@1wt.eu>
On Thu, Sep 29, 2016 at 03:48:29PM +0200, Julian Reschke wrote:
> > A more aggressive approach would be to also recommend that new parameters on existing fields (even if they specify use of 5987) SHOULD use such encoding.
> -1 to mixing different escaping rules in the same field.

That reminds me that there are some applications where you can specify a
field name for something, and the value will be passed there. What
applications do in practice is to emit "$name: $value" without checking
*anything* about $name (eg: content-length will work), and by applying
the same encoding on $value. So indeed, having possibly confusing
encoding rules is a bit tricky. BTW, I used to work on a project where
we had two different encodings depending on the field name, and one or
two fields having to carry the same value for legacy reasons, but with
a different encoding, and we found several time code parts like this :

           value = legacy_header_encode(value);
           req_ptr += sprintf(req_ptr, "legacy_name: %s\n", value);
           req_ptr += sprintf(req_ptr, "new_name: %s\n", value);

Here new_name should have been encoded with new_header_encode(). And that's
without telling about the number of times "value" is passed unencoded,
possibly carrying escape characters... Of course above it seems obvious
but when reading such code it's much less. Thus it's important to be very
careful about this.

Received on Saturday, 1 October 2016 06:28:21 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 1 October 2016 06:28:23 UTC