Re: Structured Headers: length limits

> On 16 May 2018, at 10:40 am, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On Tue, May 15, 2018 at 3:16 PM Mark Nottingham <mnot@mnot.net> wrote:
>>> 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.
> 
> Yeah, not sure if it needs action, but it stands out a little.  There's two
> competing concerns, in my view.  If these identifiers are just implemented
> as pointers to the receive buffer, there is no real cost in allowing longer
> values.  The concerns about string encoding don't really apply given the
> restrictive grammar you define.  On the other hand, it is helpful to have
> some constraints on identifiers.  But perhaps the most effective constraint
> we have is that people don't like insanely long identifiers for many other
> reasons.
> 
> I'm leaning slightly toward removing the cap here too, and establishing a
> lower expectation for minimum supported length (say 64 octets).

SGTM; I've pushed a change to the PR:
  https://github.com/httpwg/http-extensions/commit/1745c45107e22

I think we're converging here, so I'm going to merge soon unless I hear otherwise.

Cheers,

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

Received on Wednesday, 16 May 2018 03:09:50 UTC