It is completely server specific whether it is case sensitive
or not.
Default (no special options) would likely be case sensitive
on case sensitive file systems and not case sensitive on
non case sensitive file systems. You can always count on
developer laziness.
Arne
Per the semantics defined in RFC 2616, the path part of an HTTP URL is
intended to be case sensitive regardless of server behaviour:
3.2.3 URI Comparison
When comparing two URIs to decide if they match or not, a client
SHOULD use a case-sensitive octet-by-octet comparison of the entire
URIs, with these exceptions:
- A port that is empty or not given is equivalent to the default
port for that URI-reference;
- Comparisons of host names MUST be case-insensitive;
- Comparisons of scheme names MUST be case-insensitive;
- An empty abs_path is equivalent to an abs_path of "/".
Well, okay, it is a "SHOULD" and not a "MUST". However, many
important pieces of software, including caching proxies and most
search engines, will treat URLs that differ by case as being distinct
resources. Google, for example, will assign pagerank to both
resources separately, and squid will cache both separately.
This shows up in other places URLs are used: XML Namespaces that are
identified by a URL are completely case-sensitive, even within the
host portion, for example. In general, unless you have specific
knowledge of the URL scheme in use, it's best to assume that URLs are
case sensitive even if the software that's interpreting them isn't.
-o