|
Graham Dumpleton
graham.dumpleton at gmail.com
Mon Sep 29 21:21:58 EDT 2008
It may be that your assumption that setting headers_out in a authnz handler will always ensure that it appears in response, where authnz handler is not providing the final response, is just wrong. The correct way of ensuring this is possibly to use an output filter. That way the setting of additional headers is from after true handler had started returning response and so after when it has set headers itself. That way no chance that content handler will ignore what you may have already set in headers_out as you are overriding what it has set. So, have a look at req.add_output_filter(). Only thing I don't remember is whether mod_python output filters are registered at correct level to allow modifications to response headers. Graham 2008/9/30 Tom Wells <drshade at gmail.com>: > Hi Mod_Pythonians, > > So I managed to solve it - and it's clearly a bug in Apache 2.2.9 mod_proxy > as far as I can tell. I will be posting the bug to the Apache bug list, but > thought I would give you a quick explanation as I've found many a golden > nugget during my travels on this mailing list. > > Basically if you're trying to set a cookie within a handler (mod_python or > otherwise I assume) and the response from the proxied resource starts with > the "HTTP/1.1 100 Continue" status line (because the request was a POST and > had an "Expect: 100-Continue") then you can forget about mod_proxy merging > the Set-Cookie in your out_headers from your handler with the response from > the proxied resource. I've been through most of the mod_proxy code this > evening and I can understand why, there are some hairy things in there > (around backwards compatibility and the ever changing HTTP goal posts of > long ago I suppose). Regular POSTs work great, which explains the mixed > results we were seeing between our various back-end web servers. > > Of course everything works just perfectly in Apache 2.2.4 which happened to > be our development Apache version, and so we didn't stumble upon the issue > until during deployment on the production machines (which the ops team keep > patched to the latest Apache version). > > Best Regards, > Tom > > On Mon, Sep 29, 2008 at 10:05 AM, Tom Wells <drshade at gmail.com> wrote: >> >> Hi Group >> >> I'm facing an interesting problem at the moment and wondered if anyone >> could give me a pointer. Our setup is the following: >> Apache running mod_python and mod_proxy, with python handlers for Authen >> and Authz, we have an Oracle Application Server and a JRUN Application >> Server in the back, which are where mod_proxy is configured to forward to. >> Our python Authen and Authz handlers are responsible for getting and setting >> session related cookies before proxying, or to redirect the user if the >> session cookie is bad or he is not logged in (no cookie). Even if the user >> has a valid cookie we refresh it every 2 minutes, i.e. generate a new >> cookie, add the Set-Cookie header, then allow the request to continue (i.e. >> mod_proxy kicks in and forwards the request to oracle or jrun). This is nice >> because we have a single authentication model up front for multiple >> disparate web applications in the back. >> >> Now the good news is that this works really well, mostly. Browser requests >> to and from the webserver correctly get and update cookies and >> allow/disallow requests to be proxied. More specifically the "Set-Cookie" >> header is present in responses where the cookie has been updated. This is >> true for both the oracle and jrun application servers being proxied to. >> >> HOWEVER - we have a rich client (desktop) app written in C# which has been >> designed to POST to some of the oracle url's in order to fetch data, after >> it performs a login. So it logs in, gets a fresh new cookie and regularly >> hits the backend for data. For each request our Authen and Authz handlers >> process the cookie and ensure the session is valid etc, and allow or >> disallow the request (i.e. return apache.OK or do a >> mod_python_util.redirect() to get rid of him). The problem is that requests >> from this app don't ever get back a refreshed cookie (after 2 minutes) - >> there is every indication according to my apache logs that my Authz handler >> is calling the mod_python.Cookie.add_cookie(req, newCookie) function to set >> the new cookie, and even printing out the list of headers_in and headers_out >> in a fixuphandler shows the Set-Cookie header is present. BUT the Set-Cookie >> never makes it back to the app as we have used fiddler2 and httpdebugger to >> monitor the traffic. >> >> So I blame the Oracle Application Server for eating the cookie somehow, >> but surely as the cookie is added to the headers_out of the request it MUST >> go back to the browser regardless of how it was proxied or whatever the >> proxied application responds with? >> >> Please help - getting desperate for a solution - any pointers as to track >> down the issue would be greatly appreciated! >> >> Thanks, >> Tom >> >> -- >> http://www.tomwells.org > > > > -- > http://www.tomwells.org > > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python > >
|