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

On Mon, Oct 30, 2017 at 02:38:19PM +0900, Kazuho Oku wrote:
> I think that it would be a good idea to specify some limits below
> which we can expect interoperability. Something like JSON defines for
> floating numbers (i.e., numbers that fit in IEEE754 double are
> expected to have good interoperability).

+1

> I am simply against defining the limits as hard limits, since in one
> way that might be interpreted as a minimum requirement that all
> implementations must support, at the same time being an unnecessary
> complication for some of other implementations (you can essentially
> cap the amount of memory used by header parsing (including Structured
> Headers) by capping the maximum number of bytes used to transfer all
> the request headers; so why should we have another limit?).

I tend to agree on this (and have changed my initial opinion). I'm
realizing that 15 years ago haproxy was using 4kB for the whole header
block and required changing a #define and recompiling to modify it. It
used to work pretty much everywhere. Now it's 16kB by default and the
limit can be changed by configuration. It's not uncommon to see it
increased further when 16kB is too small. 4kB don't work very often
anymore nowadays. This makes me think that any reasonable limit we
could enforce right now could become complicated to work with in the
future, or induce horrible workarounds when absolutely needed.

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. But if it's
really hard and doesn't provide any benefit for a realistic use case,
better not bother implementing it. And if for any reason the best that
could be achieved was 2^48 in a much more complex way than 2^32, it's
probably pointless to do it given the expected common limits in field.
This is an example for integers as that's a common one, but this can
be applied to everything including the header block length, number of
header fields, field name length, field value length, etc.

Willy

Received on Monday, 30 October 2017 06:04:05 UTC