URI length

[mnot]

Messaging section 3 says:

Various ad hoc limitations on request-line length are found in practice. It is recommended that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.

The primary intent of that text (added in 7230) AIUI was to encourage implementations to support longer URIs. As such, I was looking for it in semantics, not messaging.

I think the best thing would be to add text somewhere in the semantics section about URIs saying that implementations should support HTTP(S) URIs of at least 8000 characters.

[annevk]

URI references, then, no?

[mnot]

Proposal:

Add to semantics 2.5.1 http URI Scheme and 2.5.2 https URI Scheme:

It is recommended that all HTTP senders and recipients support, at a minimum, http(s) URIs with lengths of 8000 octets.

[reschke]

"recommended" or "RECOMMENDED"?

[mnot]

I think the latter, but that would not be merely an editorial change (although we already have a very similar requirement).

[annevk]

Note that the combination of a long host name and the current request-line lower limit can result in a URI that's longer still. So software with long request-targets prolly needs to ensure it takes long host names into account, if it wants to fall within the overall lower limits.

[royfielding]

The current text in Messaging is correct (and already uses RECOMMENDED). My guess is that the copy-n-paste above is losing the fancy-pants styling on the all-caps. No need to change that.

Making an additional recommendation about supporting minimum URI lengths cuts across too many issues for my comfort. That would be making a requirement on the Web itself, which we have been pretty good about leaving to others. What we do have in Semantics is Section 3.3:

At a minimum, a recipient MUST be able to parse and process protocol element lengths that are at least as long as the values that it generates for those same protocol elements in other messages. For example, an origin server that publishes very long URI references to its own resources needs to be able to parse and process those same references when received as a request target.

which I still think is better than a specific number.

[wtarreau]

I like this approach. However I also know how one feels when looking for suggested limits when implementing a standard and have also heard many complaints about the lack of recommended values. Maybe we'd need to have an appendix section enumerating some limits commonly encountered on existing implementations (possibly without naming them?). In this case we could suggest in such a section that for web usage, in 2019, most agents support at least 8k URIs, 100 header fields etc...

[mnot]

The thing that's bugging me is that we're limiting a serialisation of the value in HTTP/1.1, but not the abstract value itself. That seems awkward, especially if there are version transitions for a single request chain.

[wtarreau]

But it's not really the serialization that we're limiting, it's the size of the char[] that defines its representation somewhere in the code. From this point the implementer has to adapt the serialization code to match this internal limit.

That's why I think that suggested limits outside of transport considerations is interesting. It means "the whole chain is able to pass this element, you should take care of being able to pass it as well". For example if a URI requires 8000 bytes, I know I need a larger buffer to receive a request (at least method, space, uri, space, version, 2xCRLF). I also know that my HPACK decompressor needs to be able to store 8000 bytes in the :path pseudo-header, which implies it needs to be able to store decompressed header values at least this large. It even has implications on the encoding I use for my header table implementation. All of this is independent on serialization but has to do with protocol elements, and is difficult to decide on in a consistent way along the whole chain.

[mnot]

Right, that's what I want.

[mnot]

Modified proposal:

Add to semantics 2.5.1 http URI Scheme and 2.5.2 https URI Scheme:

It is recommended that all HTTP senders and recipients support, at a minimum, http(s) URIs with lengths of 8000 octets. Note that this implies some structures and on-wire representations (for example, the request line in HTTP/1.1) will necessarily be larger in some cases.

[mnot]

Discussed in Montreal; proposal above, but all uri schemes