|
Tom Wells
drshade at gmail.com
Mon Sep 29 20:59:29 EDT 2008
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20080929/d19bcae5/attachment.html
|