Doug McNutt wrote:
At 10:44 -0700 10/24/05, [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
