Re: Structured Headers: length limits

This seems like an improvement.

I think that the underlying concern is that the amount of memory a
recipient has to allocate is essentially unbounded by the underlying
protocol.  In practice however, limits are much tighter.

Looking at the draft, you have changed in the following ways:

1. to note that there is (probably) a limit on the encoded size of header
fields, but not to say what it is.  Here it would be good to establish some
expectations about a size that is "guaranteed" to work.  That might be
unrealistic, but it would be consistent with your other
statements/recommendations regarding minimums.

2. to establish minimums for the size of structures.  This is a fine
addition, because the addition of structure to a header field can add to
the memory commitment a recipient has to make.  Establishing an expectation
that strings can be 1024 octets is good, for example.

You retain the hard upper limit on identifiers though.  Is that really
necessary?  Or is this to preserve interoperability somehow?
On Fri, Apr 20, 2018 at 4:09 PM Mark Nottingham <mnot@mnot.net> wrote:

> Hi all,

> We discussing this issue in London:
>    https://github.com/httpwg/http-extensions/issues/433

> There was a fair amount of discussion on that issue, but it's gone quiet
recently, so I thought I'd bring it up here.

> One thing that Kazuho pointed out was that we might want to consider
limiting the overall size of generated headers, rather than the individual
items.

> That started me to think about what we're trying to do here. It seems to
me that limiting the overall size of generated headers is already done by
most implementations, so we don't need to repeat that (and it could cause
some weird interop interactions). Many Structured Headers libraries aren't
going to have a way to control that (e.g., if they're written in for
PHP/CGI/Node/etc.), since they don't have access to the code that imposes
that limit (which is sometimes imposed on another box, e.g., in a CDN).

> If that's the case, what seems important is assuring that implementations
don't impose their own arbitrary limits that hurt interop. It'd also be
nice to put some limitations in so that a future alternative serialisation
of Structured Headers doesn't have to be able to encode arbitrary-length
structures.

> I've put together a PR that takes the approach of not limiting structure
sizes, but instead specifying a minimum size / enumeration that
implementations are required to support. See:
>    https://github.com/httpwg/http-extensions/pull/578

> Note that numbers and identifiers are still limited; numbers for the
various reasons already discussed, and identifiers so that they can be
reasonably transported / represented in programming languages, etc. (since
they're used as keys for parameters and dictionaries).

> Does this make sense?

> --
> Mark Nottingham   https://www.mnot.net/

Received on Monday, 14 May 2018 22:20:25 UTC