Re: If not JSON, what then ?

[Willy Tarreau <[e-mail]>]

On Wed, Aug 03, 2016 at 12:37:51PM +0300, Kari hurtta wrote:
> Willy Tarreau <[e-mail]>: (Wed Aug  3 09:46:33 2016)
> > On Wed, Aug 03, 2016 at 09:37:30AM +0300, Kari hurtta wrote:
> > > | 2) Regardless of #1, using < as your indicator character is going to collide with the existing syntax of the 
> > > | Link header.
> > > 
> > > Or perhaps use ':' as indicator? Causes double '::' on HTTP/1
> > > 
> > > Date::1470205476
> > > 
> > > Is this viable ?
> > 
> > It could but strictly speaking it will not be "::", it would just be ":"
> > to start the value, because your field above parses as ":1470205476" for
> > the value and will be rewritten like this along the path by many
> > implementations :
> > 
> >     Date: :1470205476
> 
> 
> Yes, that is true.  
> 
> Another possibility is use indicator from ascii control
> block. For example byte 01. Does not collide with existing use.
> 
> That is
> Date:
1470205476
> on HTTP/1 (but probaly not visible; first character
> after ':' is byte 01 (ctrl-A)).

It doesn't change anything. I have no problem with either proposals,
it's just that what you need to understand is that there is no such
"after ':'". The ":" is not part of the header field, it's the field
name delimitor. So before ':' you have the header field name. After
it you can have any amount of spaces (including zero) which are *not*
part of the value, and the first non-space character starts the value.

Thus, the following are exactly equivalent, though the last one is
deprecated :

    Date:
1470205476
    Date: 
1470205476
    Date:      
1470205476
    Date:
      
1470205476

> ( I think that someone suggested that already. )
> 
> ( byte 01 seems to be valid TEXT on ABNF ? )

Such bytes are rare and will have a large huffman encoding in H2. Martin's
suggestion of '><' could be more efficient, though I haven't checked.

Regards,
Willy