Re: New Version Notification for draft-nottingham-structured-headers-00.txt

On Mon, Oct 30, 2017 at 4:25 PM, Mark Nottingham <mnot@mnot.net> wrote:

> On 31 Oct 2017, at 4:36 am, Wenbo Zhu <wenboz@google.com> wrote:
> >
> > I'll ask about two more things:
> > 1) being able to separate standard headers from user-defined metadata ..
> now that we have a convention for "value" types
>
> I think that would have to be done in a new version of HTTP itself, not by
> a convention that's adopted header-by-header. I also suspect it would be
> difficult to introduce.
>
> Do we have a crisp idea of what 'user' is vs. 'standard'?
>
Anything documented in httpbis specs v.s. everything else (inc. those
specified by U-A)?



>
> > 2) a (simple) binary representation for the structure ... has it been
> discussed?
>
> Not yet, but it's in mind. Negotiating for its use would require either a
> new version of HTTP, or maybe an extension (although there'd be some
> non-optimal behaviour in the first RT).
>
Initially, "*<base64-encoded>" for user defined headers.  I can also see
such a binary representation being useful elsewhere as a _simple_ binary
serialization format.



> Cheers,
>
>
>
> >
> > Limits are useful for standard headers..
> >
> >
> > On Mon, Oct 30, 2017 at 12:14 AM, Willy Tarreau <w@1wt.eu> wrote:
> > On Mon, Oct 30, 2017 at 07:08:49AM +0000, Poul-Henning Kamp wrote:
> > > --------
> > > In message <20171030060251.GB28950@1wt.eu>, Willy Tarreau writes:
> > > >On Mon, Oct 30, 2017 at 02:38:19PM +0900, Kazuho Oku wrote:
> > >
> > > >Instead I think that explaining very common implementation limits to
> be
> > > >expected in field (eg: 2^31-1, 2^32-1 and 2^63-1 for integers) would
> > > >help implementors decide what to support and what not. Ie if it's not
> > > >harder to support 2^63 than 2^32 for integers, better do it.
> > >
> > > ... unless your programming language thinks all numbers are
> > > floating-point.
> > >
> > > The 15 digit limit is to make sure that numbers will not loose
> > > precision in a floating-point double, while still being sufficiently
> > > large for any byte-count a HTTP header can expect to ever see.
> >
> > That's still perfectly compatible with what I'm saying indeed, just
> > taking other possible implementation limits in consideration that I
> > didn't think about!
> >
> > Willy
> >
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>