On Sep 4, 2014 7:11 PM, "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
>
> --------
> In message <54088BD2.1030100@gmx.de>, Julian Reschke writes:
>
> >The main reason why I'm concerned about arbitrary binary data is that
> >all of the HTTP APIs I'm aware essentially work on character sequences,
> >not octet sequences (in header fields).
>
> That is my concern too: Most code handling HTTP today don't expect
> to see embedded NUL's, and a lot of it will happily send through
> "poison" characters like ESC.
>
> >The lack of a standard encoding in HTTP/1.1 is already a problem;
>
> But we could apply gentle persuasion here: If we make HPACK work
> really well with baser64 (it does, but could be better) a lot of
> people will take the hint. Not everybody, but a lot of them.
You are an optimist, aren't you?
People will happily choose whatever is easiest to implement and works,
especially in enterprise "intranet" environments.
So either allowed character sets are made very strict, or it's just as well
that it is not considered it a protocol issue, and is better managed at
the application framework level, where the protocol should stay as much as
possible out of the way. I'm convinced halfway measures will not achieve
anything worthy.