I'm attempting to upgrade my Pylons app to 0.9.7, but I can't seem to
get past the "302 you will now be redirected" problem.
What I did was I created a totally new Pylons app, and then I started
moving my controllers and models and things across. I'm not sure if
this is the best way, but I figured it was most probably the easiest.
I also read through the "What's new in 0.9.7" document and the
"Upgrading" document on the wiki, and followed directions as much as I
could.
I've left map.minimize on False, and I added the extra lines in my
routes.py file as per the documentation. I also made sure that my
middleware.py file had the necessary lines. I also modified base.py
and the BaseController class, because my authentication system checks
for a valid user in the __before__ function.
Now the problem comes in that when I hit the main page, my default
controller sees that there's no user logged in and tries to redirect
me to the login page. Except it just sits there saying "302 Found The
resource was found at http://localhost:5000/member/login/; you should
be redirected automatically." and never redirects me.
routes.py: http://codepad.org/d4lpLxas
middleware.py: http://codepad.org/kdnRbRpl
base.py: http://codepad.org/qIvkBnxK
Any idea what am I doing wrong?
--
Raoul Snyman
B.Tech Information Technology (Software Engineering)
E-Mail: raoul....@gmail.com
Web: http://www.saturnlaboratories.co.za/
Blog: http://blog.saturnlaboratories.co.za/
Mobile: 082 550 3754
Registered Linux User #333298 (http://counter.li.org)
I have a similar authentication system in a Pylons 0.9.7 app so I can
verify it works.
Looking at your modules, I didn't know Routes had an .append_slash
option but that could be throwing it off. There's no reason to put
slashes at the end of URLs except to make it look like a directory to
the user, but even then it's not necessary (/messages and
/messages/1234 work fine).
There's another redirect_to function in pylons.controllers.util which
you should be using instead, as routes.redirect_to is being phased
out. But they should both behave the same.
You should be putting h.url_for() around all URLs, as that will adjust
the URL if it needs a prefix someday. Or you can use Pylons 0.9.7's
fancy url() object (pylons.url), which will be its replacement in
Pylons 1.0.
You can turn on route debugging to see if it gives any clues. Add
this to development.ini:
===
[logger_routes]
level = DEBUG
handlers =
qualname = routes.middleware
===
And add 'routes' to the 'keys' option in [loggers].
If none of these help, I would check your app under Live HTTP Headers
to see what it's actually doing. The 302 response should have a
Location: header with the absolute URL to redirect to.
--
Mike Orr <slugg...@gmail.com>
I prefer ending urls with / :-D
> You can turn on route debugging to see if it gives any clues. Add
> this to development.ini:
>
> ===
> [logger_routes]
> level = DEBUG
> handlers =
> qualname = routes.middleware
> ===
Thanks to the above bit of extra debugging, I found out what my
problem was... in my routing.py (which I erroneously called
"routes.py" earlier) I had the following lines:
map.connect('/', controller='dashboard', action='index', id=None)
map.connect('/{controller}/{action}', id=None)
map.connect('/{controller}/{action}/{id}')
I had to change them to this:
map.connect('/', controller='dashboard', action='index', id=None)
map.connect('/{controller}/{action}/', id=None)
map.connect('/{controller}/{action}/{id}/')
Notice the appended slash?
Say you have a static server like this:
/dir/
index.html
other.html
The user requests "/dir/index.html", which contains a link to
"other.html". The base URL is "/dir/", so the browser does a join and
comes up with "/dir/other.html".
Or the user requests "/dir/". The server assumes the default
document, index.html. Again the base URL is "/dir/", and the relative
link resolves to "/dir/other.html".
Or the user requests "/dir". This ends in a directory so the server
issues a redirect to "/dir/", and then serves the default document.
The base URL and resolved link are the same.
If the server didn't issue a redirect but served index.html directly,
the base URL would be "/dir". The browser wouldn't know this is a
directory so it assumes "dir" is the current document and drops it
before joining:
"/dir" - "dir" + "/other.html" => "/other.html"
which is the wrong URL and doesn't exist.
In a non directory-based framework like Pylons, the choice of what to
serve for "/foo", "/foo/", and "/foo/bar" are arbitrary. Pylons can't
automatically redirect "/foo" because it doesn't know it's supposed to
be a directory. It can't divine that "/foo/bar" exists and
"/foo/NONEXISTENT" doesn't, because that's only known when those URLs
are requested. So, you have a choice:
1) Serve "/foo" as a container and let "/foo/" not exist, which is
what most Pylons apps do.
2) Redirect "/foo" to "/foo/".
3) Serve identical content for "/foo" and "/foo/".
4) Serve different content for "/foo" and "/foo/".
The trouble with #4 is thinking up a practical case for it. When do
you need two slightly different indexes? Perhaps a title page and a
table of contents. But nobody does it that way, and it's prone to
human misperception or browser misperception given the precendent of
static files.
The corollary is that relative URLs don't work with the default Pylons
case. You may be able to get from "/foo/bar" to "/foo/baz" with a
link to "baz", and if you're lucky you might be able to get to
"/foo/index" with "./", or "/foo" with "..", but it depends on your
routing. This is one reason why Pylons (and TurboGears and Rails)
discourage relative URLs in favor of url_for(), which generates a
fully-qualified, unambiguous URL.
Another aspect is that users don't like to type trailing slashes.
They also don't know whether something is a container, so they'll type
"http://example.com/articles" because somebody told them there's an
articles URL.
--
Mike Orr <slugg...@gmail.com>
Either is fine (you can have a redirect for 1 too). The most important
thing is just not to be ambiguous. And you should probably do redirects.
> 3) Serve identical content for "/foo" and "/foo/".
Not uncommon but VERY BAD. Don't even consider doing this.
> 4) Serve different content for "/foo" and "/foo/".
Uncommon BUT ALSO BAD. Zope 2, in a fit of cleverness, does this --
adding <base href> to one of those so the links work equivalently for
either. It's a horrible awful thing. Resources and URLs should be
one-to-one. Ambiguous URLs are one of those things in Zope that have
scarred me, and seeing how hard that makes other things has made me
sensitive to ambiguity elsewhere.
--
Ian Bicking : ia...@colorstudy.com : http://blog.ianbicking.org