Re: If not JSON, what then ?

[Willy Tarreau <[e-mail]>]

Hi Mark,

On Tue, Aug 02, 2016 at 01:33:39PM +0200, Mark Nottingham wrote:
> 1) Using the first character of the field-value as a signal that the encoding
> is in use is interesting. I was thinking of indicating it with a suffix on
> the header field name (e.g., Date-J). Either is viable, but I don't think
> it's a good idea to reuse existing header field names and rely on that signal
> to differentiate the value type; that seems like it would cause a lot of
> interop problems to me. Defining a new header field (whether it's Date-J or
> Date2 or whatever) seems much safer to me.

I had the same feeling initially but I retracted. I fear that having two
header fields will result in inconsistencies between the two (possibly
intentional when that may be used to benefit an attacker). We'd rather
avoid reproducing the Proxy-Connection vs Connection mess we've been seeing
for a decade, where both were sent "just in case".

However if we enumerate certain header fields that would deserve being
encoded differently and find a way to group them, we may think about
sending a composite, compact header field for transport/routing, another
one for the entity where available information are grouped when relevant.
Then maybe it could be decided that when one agent consumes such a field,
before passing the message it must delete occurences of the other ones,
and/or rebuild them from the composite one, in order to avoid inconsistency
issues.

We have more or less this regarding Transfer-Encoding which voids
Content-Length, and the Host header field which must always match the
authority part of the URI if present.

These are just thoughts, maybe they are stupid.

Willy