|
Tom Wells
drshade at gmail.com
Mon Sep 29 21:49:57 EDT 2008
Good point and something that was bothering me before I looked at mod_proxy_http.c - which clearly was built with the "intention" of merging proxied responses with values already set in headers_out. But in terms of defensive programming and designing for the unexpected, especially within a flexible framework such as Apache is very good advice. I'll take a look at add_output_filter() and see if it's a better option for me. Thanks for your help as usual Graham. Best Regards, Tom On Mon, Sep 29, 2008 at 9:21 PM, Graham Dumpleton < graham.dumpleton at gmail.com> wrote: > 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 > > > > > -- 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/795c708c/attachment-0001.html
|