Case in-sensitive paths ?

[viper]

This is under my virtual host and works great:
WSGIScriptAlias /login /var/wsgi/login.wsgi

http://mysite.com/login <-- works.

How do I make it so "login" can be case in-sensitive? Login, LOGIN,
LoGiN ?

I placed the following in my WSGI.CONF file (apache2) which gets
imported into apache2.conf on server restart along with the modules:

WSGICaseSensitivity Off

And restarted my server. However, not working... /login <-- works, /
Login <-- not working

Anything else I need to do?

[Ben Timby]

The WSGICaseSensitivity only works on URLs mapped underneath the
alias. Since apache is mapping /login to your application before WSGI
get a hold of you, you can do one of two things.

1. Map / to your WSGI app, and then login/Login/LOGIN will all be handled by it.
2. Make apache case-insensitive? Perhaps:

http://httpd.apache.org/docs/2.2/mod/mod_speling.html

[Deron Meranda]

On Mon, Jun 14, 2010 at 3:54 PM, Ben Timby <bti...@gmail.com> wrote:
>> http://mysite.com/login    <-- works.
>>
>> How do I make it so "login" can be case in-sensitive?  Login, LOGIN,
>> LoGiN ?

> 1. Map / to your WSGI app, and then login/Login/LOGIN will all be handled by it.

> 2. Make apache case-insensitive? Perhaps:

Or 3. Use multiple mappings for the expected common variants.

WSGIScriptAlias /login /var/wsgi/login.wsgi
WSGIScriptAlias /Login /var/wsgi/login.wsgi
WSGIScriptAlias /LOGIN /var/wsgi/login.wsgi

because, really, do you expect to see "LoGiN"?

However, you should consider whether you really do want case
insensitivity anyway. Some may argue that web resources should
have a single well-known canonical name. After all, URLs
and URIs are generally case-sensitive anyway (except for the
hostname portion, which because of historic DNS conventions
are case-insensitive).

Also by having multiple case-variants for your URLs you may
be defeating web caching, spiders (for search engines),
and so forth.

If you want to allow for case insensitivity yet still have a single
canonical URL, you should really use redirects,

Redirect permanent /Login /login
Redirect permanent /LOGIN /login

--
Deron Meranda
http://deron.meranda.us/

[viper]

Thanks Ben and Deron. Informative.

[Graham Dumpleton]

I concur with all comments made, you want to avoid having case
insensitive URLs for the reasons stated.

On 15 June 2010 06:31, Deron Meranda <deron....@gmail.com> wrote:
> On Mon, Jun 14, 2010 at 3:54 PM, Ben Timby <bti...@gmail.com> wrote:
>>> http://mysite.com/login    <-- works.
>>>
>>> How do I make it so "login" can be case in-sensitive?  Login, LOGIN,
>>> LoGiN ?
>
>> 1. Map / to your WSGI app, and then login/Login/LOGIN will all be handled by it.
>> 2. Make apache case-insensitive? Perhaps:
>
> Or 3. Use multiple mappings for the expected common variants.
>
> WSGIScriptAlias /login /var/wsgi/login.wsgi
> WSGIScriptAlias /Login /var/wsgi/login.wsgi
> WSGIScriptAlias /LOGIN /var/wsgi/login.wsgi

Just be a little bit careful with doing this.

Normally mod_wsgi assigns a distinct Python sub interpreter within
each process based on the mount point.

From memory though it will make URL mount point all lower case before
calculating sub interpreter to use. Thus all the above should resolve
to same sub interpreter.

You may want to verify that by looking at value of
'mod_wsgi.application_group' in WSGI environ dictionary.

To be safe, you can be explicit and add:

WSGIApplicationGroup %{GLOBAL}

which forces them to all use main interpreter.

Graham

> because, really, do you expect to see "LoGiN"?
>
>
> However, you should consider whether you really do want case
> insensitivity anyway.  Some may argue that web resources should
> have a single well-known canonical name.   After all, URLs
> and URIs are generally case-sensitive anyway (except for the
> hostname portion, which because of historic DNS conventions
> are case-insensitive).
>
> Also by having multiple case-variants for your URLs you may
> be defeating web caching, spiders (for search engines),
> and so forth.
>
>
> If you want to allow for case insensitivity yet still have a single
> canonical URL, you should really use redirects,
>
> Redirect permanent /Login /login
> Redirect permanent /LOGIN /login
>
> --
> Deron Meranda
> http://deron.meranda.us/
>

> --
> You received this message because you are subscribed to the Google Groups "modwsgi" group.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
>
>

[Jason Garber]

Have you considered a simple mod_rewrite rule?

RewriteEngine on

RewriteCond ${REQUEST_URI} !=/login  

RewriteRule ^/login$  /login  [NC,PT,L]

See http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html  -- search for [PT]

Or perhaps even better, use a redirect:

RewriteEngine on

RewriteCond ${REQUEST_URI} !=/login  

RewriteRule ^/login$  /login  [NC,R,L]

That insulates your application from this issue, and maintains a consistent URL even if people *get* there using /LoGiN

-JG

On Mon, Jun 14, 2010 at 3:23 PM, viper <jscn...@gmail.com> wrote:

[Graham Dumpleton]

On 16 June 2010 09:13, Jason Garber <bo...@gahooa.com> wrote:
> Have you considered a simple mod_rewrite rule?
> RewriteEngine on
> RewriteCond ${REQUEST_URI} !=/login
> RewriteRule ^/login$  /login  [NC,PT,L]
>
> See http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html  -- search for
> [PT]
> Or perhaps even better, use a redirect:
> RewriteEngine on
> RewriteCond ${REQUEST_URI} !=/login
> RewriteRule ^/login$  /login  [NC,R,L]
>
> That insulates your application from this issue, and maintains a consistent
> URL even if people *get* there using /LoGiN

You may have to be a bit careful from memory as REQUEST_URI hasn't
been decoded. Would pick up the bulk of cases though and only where
user did something stupid wouldn't it work. :-)

Graham