Doug McNutt wrote:
At 10:44 -0700 10/24/05, dogbert@xxxxxxxxxxxxx wrote, in part:. . . as opposed to general case-insensitivity which is not possible (and, in addition, not advisable, since proxy caches, search engines, etc are all case sensitive).Well, Google is case INsensitive and proud of it.
Try... http://www.google.com/preferences?hl=en http://www.google.com/Preferences?hl=en Query strings have nothing to do with resource paths.
Think Mac OX neXt. . . I have a local machine named Gallifrey running Linux. I place an entry for it into my /etc/hosts file pointing to 192.168.1.26. Asking Safari to access Apache at http://Gallifrey fails!. The Someone changes the URL to http://gallifrey. Placing a parallel entry in /etc/hosts named gallifrey fixes it up. The doctor deserves to have his home planet capitalized.
The HOSTNAME is case insensitive. The resource name is not. See the respective RFC's and STD documents.
It appears that OS neXt converts everything to lower case expecting a DNS server to be case insensitive, as per URL specifications, when its own nslookup fails when looking into a local hosts file.
That's a bug on OS neXt, but is inapplicable to this whole discussion. Scheme and hostname are case insensitive. User/Password is application-defined. Resource is case sensitive. Query string is application defined. None of this is germane to the discussion at hand :) Bill --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|