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

[Willy Tarreau <[e-mail]>]

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.

Cheers,
Willy