allow line break at operators

Roy Smith roy at
Mon Aug 15 00:46:24 CEST 2011

In article <mailman.2285.1313358379.1164.python-list at>,
 Dave Angel <davea at> wrote:

> > URLs are most certainly not case insensitive.  Parts of them may be
> > (i.e. the scheme and host parts), but not the stuff after the hostname.
> >
> The thing that confuses people is that not only is the part up to and 
> through the domain name is case-insensitive, but that simple pages on 
> Windows become case-insensitive for the remainder simply because Windows 
> is such.

Sure.  But it's only in the most trivial of situations that URLs map in 
any trivial way to file names.

> And the same page hosted on Linux would be case sensitive, per 
> specification.

Well, I certainly could write an HTTP server on Linux which treated 
routes in a case-insensitive way.  For example, if I do a GET on, I get redirected to  On the other hand, gets me a 404.  It's entirely up 
to the server to do whatever makes sense for that application.

> The thing I find annoying is a host that decides that if a URL is close 
> to an existing URL, it'll fix one or two "typos."  To me, it's either 
> right, or it's not.  Don't change   
> to  www/ and pretend it's "close enough."

Hosts don't decide anything.  Applications running on those hosts decide 
things.  Without knowing the application, it's impossible to say if this 
is the right thing to do or not.

For example, it's good practice that if a URL ever worked in the past, 
you should keep that URL working, even if it becomes "obsolete".  You 
might want to silently return some other page, or redirect the user to 
some other URL.  This keeps bookmarks, existing links, cached search 
results, etc, from going stale.

To use the wikipedia example again, there are lots of redirect entries, 
for other (perhaps incorrect) spellings, and so forth.  For example,

More information about the Python-list mailing list