Re: scheme-specific length limits (issue 48)

Just catching up on this thread...

HTTPbis has added the following language re: HTTP, FWIW:

   HTTP does not place a pre-defined limit on the length of a request-
   target.  A server MUST be prepared to receive URIs of unbounded
   length and respond with the 414 (URI Too Long) status code if the
   received request-target would be longer than the server wishes to
   handle (see Section 8.4.15 of [Part2]).

   Various ad-hoc limitations on request-target length are found in
   practice.  It is RECOMMENDED that all HTTP senders and recipients
   support request-target lengths of 8000 or more octets.

Note that we're not limiting the URL itself, but rather the syntactic form on the wire (which never includes fragment identifiers, and often doesn't carry the scheme or authority).

Cheers,


On 03/04/2011, at 4:45 AM, Noah Mendelsohn wrote:

> On 4/1/2011 1:38 AM, "Martin J. Dürst" wrote:
>> Allowing URIs/IRIs to be of 'abritrary' length (as we currently do) doesn't
>> mean that all implementations have to handle URIs/IRIs of arbitrary length.
>> Last time I heard about this issue (which I have to admit was a while ago),
>> various browsers had various (rather high, like 4096 or so) limits. Longer
>> ones should just be handled 'gracefully', i.e. result in "not resolvable"
>> rather than "application blows up". Implementations have to do that anyway,
>> because a limit in the spec isn't a guarantee to not find longer ones in
>> the wild.
> 
> I agree as far as that goes. What I was implying, and of course you may disagree, is that for particular schemes there may be still be some value in specifying that no legal URI will exceed some particular length. Those who build implementations will then be assured that their code will indeed handle all correct URIs, and can also avoid the temptation to even try to do anything other than rejecting longer ones. Setting a limit also establishes clear guidance for those minting URIs (though I agree that could be handled with a SHOULD in the spec in any case), and gives greater assurance that URIs within that limit will not (should not) be rejected by >any< implementation.
> 
> All of that said: I strongly agree with the general sense that, when in doubt, length limitations in the specifications are to be avoided. I was merely pointing out that your characterization of them as "total nonsense" seems a bit strong. There certainly is an upside as well as a downside in some cases.
> 
> Noah
> 

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

Received on Monday, 4 April 2011 06:01:27 UTC