[albatross-users] Re: pre4 - Problems still ...

[Andrew McNamara]

>OK, I've been working on this, and I do agree now that there is/are
>error(s) in my code causing the session to drop.

One thing I find useful is to comment out the call to remove_session in
app.py, Application.handle_exception(). I'm not sure if this will be as
helpful in a randompage app, but it's very handy for other deployment
options.

>There is definitely something different about the error handling in pre4 as
>opposed to previous versions of Albatross.

The error *handling* largely hasn't changed, but it could be that pre4
is picking up an error (and raising an exception) that previous versions
let pass silently, or that pre4 is botching headers.

>The error you mention above is essentially a 404 error. There was no al-img
>tag, but my commonmacros.html file did have a normal HTML <img> tag and the
>image refereced was not on the server, and so should generate a 404 error.

I wouldn't have thought that would cause the symptoms you are seeing.

>But, even if I fix that problem, there are other errors I've found, such as
>expressions not being defined in the local context name space. Before these
>always took me to the default Albatross error page (which I've not tried to
>overwrite) with a nice traceback. When this happened, I KNEW that something
>in my code was wrong.
>
>Now it is not doing that. It is taking me to the expired session page in my
>application and the only way I can see the tracebacks for anything (it
>seems) is by sniffing packets.

What can cause this is if the rendered html template contains references
back to other albatross rendered content (so, for example, frames or
images). What happens is that one frame or image gets an exception, and
when the next one is fetched by the browser, the session has been removed.
The fact that you are seeing a traceback going over the wire, but not
seeing anything rendered in your browser strongly suggests a non-html
object is to blame (an image?).

Another possibility is that the traceback you're seeing go past is being
interpreted by the browser as HTTP headers and hidden for that reason
(which would tie in with the theory you mention below). Maybe you could
mail a text dump of the trace to me and I see if I can tell which
option it is? If you can't get ethereal to produce a text dump, do
something like:

    # tcpdump -s 2000 -n -w /tmp/alba-dump port 80

Then gzip the /tmp/alba-dump file and mail it to me.

>I'm not a neophyte cgi programmer, although I'm no expert either. But I
>have a fair/modest amount of experience in this area, and I've never had
>to sniff packets before to read the error messages sent by a Python cgi
>script.
>
>:(

It does tend to be a technique best used when all others have failed. The
last time I used it in this context was debugging the "file" input
handling (to see the mime headers)... 8-)

>Is this again something peculiar to the redirect/random URL type of
>applications?

Well, they do have a lot of gotchyas that don't apply to other application
models - I tend to try to avoid them for that reason.

>It looks to me like this new send_redirect function could be the culprit?
>Or is at least involved in some way?
>
>    def send_redirect(self, loc):
>        cookie = self.get_header('Set-Cookie')
>        if cookie:
>            self.request.write_header('Set-Cookie', cookie)
>        return self.request.redirect(loc) 
>
>Could this be the reason that after the handle_exception method prints out
>the traceback, that the request is still redirected to the previously
>requested redirect page? If so, IMO this behavior should be modified.
>handle_exception should print the output (traceback) and then halt.

Ah - that sounds like a good theory. Dave?

>I'm just grasping about to try and think why it is so flipping hard for me
>to see that there are errors in my code, when with previous versions of
>Albatross it was easy.

It certainly should be easy...

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/