- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 20 Apr 2018 15:58:08 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
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 Friday, 20 April 2018 05:58:38 UTC