Re: Structured Headers: length limits

> On 15 May 2018, at 8:19 am, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> 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.

Yes. Overall, I think that's probably better done in draft-ietf-httpbis-semantics, since these limits are often imposed by components that aren't under the control of a SH implementation (e.g., a Web server, proxy server, or browser), and since it'd affect all headers, not just structured ones.

That said, SH could explain the situation better. I'll modify the PR.


> 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?

I struggled with this; since it's used for dict and parameter names, it seemed reasonable to be a bit more constraining here. Happy to open it up if that causes discomfort.

Cheers,



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

Received on Tuesday, 15 May 2018 05:17:15 UTC