On 13 February 2010 00:21, Gunnlaugur Thor Briem <[email protected]> wrote: > On Fri, Feb 12, 2010 at 6:01 AM, Graham Dumpleton > <[email protected]> wrote: >> >> If you really want to go down that path, happy to try and get that C >> extension module together for you, but with apswigpy you could at >> least test concept first. > > That's really good of you to offer. But you mean making this extension > module as a sort of minimal subset of apswigpy, using the same approach, > right?
No and yes. The apswigpy module uses SWIG, I am talking about a hand crafted C extension module for just the specific purpose required. It still would effectively do the same thing but without the extra baggage of apswigpy. > So it too would only work in embedded mode? Yes, would still only work in embedded mode. >I'll gladly try out > apswigpy and tell you how it goes, but in the end I will probably want to > avoid changing over to embedded mode if at all possible. >> >> The only way around that would be for mod_wsgi to provide a special >> feature whereby you could provide a response header which specifies >> the user and mod_wsgi picks that up in main Apache server processes, >> whether embedded or daemon mode used and makes update transparently. > > This actually sounds quite neat and minimal — if it's an obviously > non-conflicting header like X-modwsgi-trans-request-user that gets removed > on the Apache side so it only exists over the daemon process divide, and > only exists when specifically configured, that would be a fairly safe and > low-effort feature to add, right? And works in either embedded or daemon > mode. > Are there more cases besides the authenticated username, of information that > people might commonly want to pass back to Apache? I'm wondering if this is > a special case or whether a general scheme like 'X-modwsgi-trans-%s' for > string-valued key-value pairs is warranted. Personally I don't like the X-Header practice. In CGI 1.2 they propose a special header called Script-Control. See: http://tools.ietf.org/id/draft-rfced-info-coar-00.txt Since how WSGI scripts are mapped in mod_wsgi is not much different to how CGI scripts are mapped and WSGI has its derivations from CGI, I think that this Script-Control header would make more sense. You can see one example of where a web server has used Script-Control to implement various control mechanisms that scripts can trigger at: http://wasd.vsm.com.au/wasd_root/doc/scripting/scripting_0200.html just seach for Script-Control. My only issue with Script-Control is am not sure how well defined what you provide as value to it is. That VMS server uses ';' as separator, but not sure if that is correct. The CGI specification says: Script-Control = "Script-Control" ":" 1#control-directive NL control-directive = "no-abort" | extension-directive extension-directive = *<CHAR, excluding CTLs, NL> So, no mention of a separator and not even sure it supports the return of multiple control directives. Since from what I have seen no other server besides that VMS server has ever implemented Script-Control even if did the same it isn't likely to upset anything else. In the past the control directives I have thought could be useful were: X-add-output-filter - Add a named Apache output filter to output filter chain for this request. X-remove-output-filter - Remove a named Apache output filter from output filter chain for this request. Another might be used to override default WSGI output buffering requirements. Ie., instead of flushing after every yielded value, wait until some defined buffer size is exceeded and then flush so as to try and avoid flushing of small data chunks. So, along these lines one could also have: X-remote-user - Set the authenticated user for this request so long as a authentication handler wasn't already noted as having determined this and set the user. X-auth-type - Set the name of the mechanism used to authenticate the user. In other words, would only override req->user in Apache request if req->ap_auth_type wasn't previously set. This check is just to ensure that an application cant override what was already calculated by a prior Apache authentication module. Anyway, idea is you would return response header of: Script-Control: X-remote-user=grahamd; X-auth-type=Session/Django Setting the authentication type possibly serves no purpose as the places where it is consulted are in earlier phases of request handling in Apache. >> Because users wanted me to stick with mod_wsgi really only being about >> WSGI. I did think about making it part of mod_wsgi. But then I would >> have still had to maintain it even though no one was using it. > > Fully understood. Would this apply also to the transient-header-passing > approach above? I.e. is it too out-of-scope to be included, and thus should > be a separate module? Not necessarily as it melds well with my prior thoughts on allowing some measure of control of Apache request handling through Script-Control response header. Graham > I imagine (unfoundedly) that it would be a fairly > commonly-desired feature though. > Thanks, > - Gulli > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
