- From: William A. Rowe, Jr. <wrowe@rowe-clan.net>
- Date: Mon, 18 Aug 2008 22:12:31 -0500
- To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>
- CC: ietf-http-wg@w3.org
Frank Ellermann wrote: > For your other remark about the length of file names > in bytes (about 150): You said this boils down to 17 > code points. 150 / 3 / 17 is about 2.9, so far it's > clear. But the "3" in 150 / 3 is apparently for the > percent-encoding (?) > > A file system supporting Unicode (UTF-8 or UTF-16) > should be able to store about 50 or 75 code points. > > IMO file name length limits don't belong in 2616bis: > > <joke> Everybody knows that the limit is 8+3, 8+8, > 14, 99, 255, or something else in octets for EBCDIC, > ASCII, OEM, ANSI, UTF-8, UTF-16, or similar. </joke> Most filesystems will take a filename between 248 and 255+ characters. I'm not sure why folks are scared of long headers, they've existed forever (cookies, et al), but there's no reason to set arbitrary recommendations on this point. There are security holes of being unable to represent a file path in one context that had been already represented in another context. The "system limit" is the only gating factor, and sane authors will choose something reasonable for most implementations.
Received on Tuesday, 19 August 2008 03:13:24 UTC