The mod_python wiki has materialized!
Woot Woot Woot! We have our wiki! http://wiki.apache.org/mod_python/ Now comes the hard part... what the heck are we going to do with it? :) Jim
Re: The mod_python wiki has materialized!
Graham Dumpleton wrote: On 13/09/2006, at 8:45 AM, Jim Gallacher wrote: Woot Woot Woot! We have our wiki! http://wiki.apache.org/mod_python/ Now comes the hard part... what the heck are we going to do with it? :) Ahhh, more work. :-( Obviously the FAQ stuff can go over there, but I would really like to see the main LaTeX documentation converted and hosted there so it can be updated more easily. Might have to ask Grisha's opinion on that, he might want to see something be able to still be downloadable with the source code itself. In practice though, how many actually use the LaTeX source to generate their own documentation, I would guess most go to the web site anyway. We would have to be careful though to make sure we annotate features to show over time at which version they were introduced, since we will not have parallel snapshots of documentation for each major release. Regarding hosting the official documentation within a wiki... A topic that has recently come up on infra@ is that anything that is editable by people without ASF CLAs on file is ineligible to be shipped as part of an official Apache release. Just thought I ought to call attention to that point, if wiki-fication of the main docs is being considered. Other projects have approached this by having two separate wikis, the documentation one being write-access-restricted to CLA-ed people. Max. signature.asc Description: OpenPGP digital signature
Re: how to get the temp file name
That does work, but it won't get me where I need to be. The problem is that the spoolfile isn't set after a parsing error - there is no brigade in param-upload upon a bad parse. I did find a simple way to get a filter in there: apreq_hook_t * my_hook_handle = apreq_hook_make(req-pool, my_hook, NULL, NULL); apreq_hook_add(aph, my_hook_handle); I think I'll be able to set a note with this technique. Brian McQueen On 9/12/06, Issac Goldstand [EMAIL PROTECTED] wrote: Well, the spool file is just a normal apr_file_t, and the actual file handle is accessable via apreq_brigade_spoolfile(), so you'll likely want to do something like: (untested) char[255] filename; apr_status_t rv; rv = apr_file_name_get(filename, apreq_brigade_spoolfile(param-upload)); Issac Brian McQueen wrote: I am trying to figure out how to get the name of the temp file created by apreq when it spools to the disk. I have been through several tries now and the most promising seems to be making a hook and adding it to the parser. The hook would get the name from the brigade as the request is parsed, then it could put the name into a note which my module could get later. I'm struggling now to add my hook to the parser. I have a parser function, but not a parser_t at that stage of my code - prior to reading and parsing - and the add_hook function requires a parser_t. At this stage the parser is not yet set. How can I directly add a hook to the parse_multipart parser? Do any of you have any better ideas? Brian McQueen
Setting new POST_MAX or MAX_BODY
I'm trying to raise my post maximum and keep getting this error:[error] [client 127.0.0.1] (20014)Internal error: Content-Length header (959543540) exceeds configured max_body limit (67108864)How do I set max body higher? So far I have:sub handler { my $r = shift; my $req = Apache2::Request-new( $r, POST_MAX = "5", MAX_BODY = "5" );}1;What am I doing wrong? Thanks, Boysenberry boysenberrys.com | habitatlife.com | selfgnosis.com
why does ap_invoke_handler init input filters?
Hi all, I've been trying to solve my confusion on the exact order of hooks and filters being invoked inside an HTTP request, and was wondering why ap_invoke_filter_init(r-input_filters) is called inside of ap_invoke_handler (server/config.c:338) ? I can understand initializing output filters at this point, but input filters that want to work with the request headers would have been inserted at the create_request hook (and invoked by the time we got to post_read_request and the quick-handler, let alone the response handler), so what are we really trying to initialize at this point? Thanks for the insight, Issac
Re: why does ap_invoke_handler init input filters?
If I went to all that trouble to give a line number below, I should probably mention that I'm looking at the 2.2.3 release. Sorry for not mentioning that the first time around. Issac Goldstand wrote: Hi all, I've been trying to solve my confusion on the exact order of hooks and filters being invoked inside an HTTP request, and was wondering why ap_invoke_filter_init(r-input_filters) is called inside of ap_invoke_handler (server/config.c:338) ? I can understand initializing output filters at this point, but input filters that want to work with the request headers would have been inserted at the create_request hook (and invoked by the time we got to post_read_request and the quick-handler, let alone the response handler), so what are we really trying to initialize at this point? Thanks for the insight, Issac
AW: why does ap_invoke_handler init input filters?
-Ursprüngliche Nachricht- Von: Issac Goldstand Gesendet: Dienstag, 12. September 2006 12:04 An: dev@httpd.apache.org Betreff: why does ap_invoke_handler init input filters? Hi all, I've been trying to solve my confusion on the exact order of hooks and filters being invoked inside an HTTP request, and was wondering why ap_invoke_filter_init(r-input_filters) is called inside of ap_invoke_handler (server/config.c:338) ? I can understand initializing output filters at this point, but input filters that want to work with the request headers would have been The purpose of input filters is to process the request body (if present of course). If you want to do something on the request headers you need to do this in a diffferent hook (e.g. header_parser). See also mod_setenvif as an example. inserted at the create_request hook (and invoked by the time we got to post_read_request and the quick-handler, let alone the response handler), so what are we really trying to initialize at this point? Thanks for the insight, Issac Regards Rüdiger
suexec for directories
I'm currently involved in building a new webserver environment to replace a 6 year old server running a large website with a fairly broken publishing model. One of the things we'd like to do is lock down PHP so that we're no longer using mod_php running all as one user, and this means using cgi mode under suexec. The kicker is that we can't use a separate vhost for each department/publishing group for various political reasons. Naturally, the suexec documentation says do not edit this on pain of death, etc, but we don't seem to have any choice if we want to support suexec configuration local to the directory stanza. I can understand why only virtualhosts were supported under 1.3, as suexec seems to be a massive hack that co-opts the User and Group directives, but mod_suexec under apache 2.2 seems much cleaner. What I would like to know is, a) is there a big obvious answer to this that I'm missing, and b) does the following diff for mod_suexec.c open up subtle and terrifying security holes that we've managed to overlook? 63c63 const char *err = ap_check_cmd_context(cmd, NOT_IN_DIR_LOC_FILE|NOT_IN_LIMIT); --- const char *err = ap_check_cmd_context(cmd, NOT_IN_LIMIT); 118c118 AP_INIT_TAKE2(SuexecUserGroup, set_suexec_ugid, NULL, RSRC_CONF, --- AP_INIT_TAKE2(SuexecUserGroup, set_suexec_ugid, NULL, RSRC_CONF|ACCESS_CONF, Many thanks, Ben
Re: suexec for directories
On Tue, September 12, 2006 5:26 pm, Ben Charlton wrote: One of the things we'd like to do is lock down PHP so that we're no longer using mod_php running all as one user, and this means using cgi mode under suexec. The kicker is that we can't use a separate vhost for each department/publishing group for various political reasons. You could use a single vhost per department/publishing group on a private localhost webserver install (or multiple private localhost installs), and then switch in each vhost into your mail website wherever it needs to live using ProxyPass and mod_proxy_http. You would only need do this for departments actually using php, which in theory wouldn't be the default, and your departments will not even see this is happening. Regards, Graham --
Re:[Bug 31759] - default handler returns output filter apr_status_t value
On 12 Sep 2006, at 22:27, [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2006-09-12 21:27 --- The PUT handler is a small 10 line script. It absolutely doesn't return a code 70007 or anything other than 0 no matter how it finishes. This is not resolved nor fixed. The bug is fixed, because it refers explicitly to the default handler. However, mod_cgi at line 840 and mod_cgid at line 1390 have the same issue when the input filters return an error. I think the easy fix is to return 500 there, unless we can blame the client and return 400. -- Nick Kew
Re: [RELEASE CANDIDATE]: Apache-Test-1.29-RC1
On Thu, 7 Sep 2006, Philip M. Gollucci wrote: A release candidate for Apache-Test 1.29-RC1 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.29-rc1.tar.gz +1. Tested on - Win32: Apache/2.2.3 (winnt) - linux: Apache/2.0.55 (prefork) -- best regards, Randy
