Title: Reading Directory Name from command_rec[]
When I write a function to handle configuration directive in a module,
Is there a way I can pass the Directory Name in which the directive occurred ?(to the handler function)
Or should I handle it seperately in dir_config function ?
this allows you to pass a 'path' to the fast cgi process
to use:
ProxyPass /forum fcgi-tcp://127.0.0.1:8005/foruX
request
/forum/zx will have a path_info of /foruX/zx
posting it as a patch, as the code is a bit fugly.
Index: mod_proxy_fcgi.c
On 01/03/2006 06:15 PM, Jim Jagielski wrote:
On Jan 2, 2006, at 4:18 PM, Ruediger Pluem wrote:
1. Proposal
If a subrequest has a broken backend also set r-no_cache for the
main request
and ensure that the chunk filter does not sent the last chunk marker
in this case.
2. Proposal
On Thu, Jan 05, 2006 at 12:48:25PM +0100, Ruediger Pluem wrote:
But I remember myself that there had been casting issues in the past that
created compiler warnings especially with gcc 4. The patch below compiles
fine with my gcc 3.2.2 with -Wall. So if someone could give a comment
if
f-ctx
On 01/05/2006 12:58 PM, Joe Orton wrote:
On Thu, Jan 05, 2006 at 12:48:25PM +0100, Ruediger Pluem wrote:
[..cut..]
André's trick of using invented unique pointers by doing:
static char sentinel; (in global scope)
f-ctx = sentinel;
is neater and avoids the casting mess. (pick a
Hi,
After some problems with SORBS, I can finally answer.
* Paul Querna [EMAIL PROTECTED] [2006-01-04 22:09:28]:
(gdb) print r-finfo-fname
$1 = 0x6041b937
/[EMAIL PROTECTED]
The source .mbox for this message id is:
ws-axis-c-dev/200503.mbox
Quite funny actually. I recall a
I noticed that in ap_proxy_http_process_response of mod_proxy_http.c we never
call apr_brigade_destroy for the locally created brigade bb.
We only call apr_brigade_cleanup on this brigade.
Isn't this a memory leak?
Regards
Rüdiger
On 01/02/2006 04:14 PM, Ruediger Pluem wrote:
I just noticed that c-aborted does not get set on trunk when you abort a
connection in the browser (with worker mpm,
but I guess with prefork is the same).
This works in 2.2.x. I guess this has something to do with the async write
refactoring
Ruediger Pluem wrote:
On 01/02/2006 04:14 PM, Ruediger Pluem wrote:
I just noticed that c-aborted does not get set on trunk when you abort a
connection in the browser (with worker mpm,
but I guess with prefork is the same).
This works in 2.2.x. I guess this has something to do with
On Thu, Jan 05, 2006 at 04:36:10PM +0100, Ruediger Pluem wrote:
I noticed that in ap_proxy_http_process_response of mod_proxy_http.c we never
call apr_brigade_destroy for the locally created brigade bb.
We only call apr_brigade_cleanup on this brigade.
Isn't this a memory leak?
With the
On Thu, Jan 05, 2006 at 05:02:54PM +0100, Ruediger Pluem wrote:
On 01/02/2006 04:14 PM, Ruediger Pluem wrote:
I just noticed that c-aborted does not get set on trunk when you abort a
connection in the browser (with worker mpm,
but I guess with prefork is the same).
This works in
On Thu, Jan 05, 2006 at 11:12:25AM -0500, Jim Jagielski wrote:
This is all, afaikt, due to the port of the async branch changes
to trunk, which I believe Roy has asked be reverted.
Not quite. Brian used multiple async branches. One is async write, one is
for async reads. The one Roy has
On Thu, Jan 05, 2006 at 08:14:58AM -0800, Justin Erenkrantz wrote:
I do note that the 2.0 code says:
/* The client has aborted, but the request was successful. We
* will report success, and leave it to the access and error
* logs to note that the
Justin Erenkrantz wrote:
Why are we masking the non-EAGAIN error values too? I'd prefer that we
continue to return the error code for everything but EAGAIN - like the
current code does. (Setting c-aborted here probably does make sense
though.)
+1
--
Any idea why we no longer ap_update_child_status with
SERVER_BUSY_LOG before we call ap_run_log_transaction ??
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a
On Thursday 05 January 2006 16:13, Joe Orton wrote:
On Thu, Jan 05, 2006 at 04:36:10PM +0100, Ruediger Pluem wrote:
I noticed that in ap_proxy_http_process_response of mod_proxy_http.c we
never call apr_brigade_destroy for the locally created brigade bb.
We only call apr_brigade_cleanup on
On Thursday 05 January 2006 11:58, Joe Orton wrote:
On Thu, Jan 05, 2006 at 12:48:25PM +0100, Ruediger Pluem wrote:
But I remember myself that there had been casting issues in the past that
created compiler warnings especially with gcc 4. The patch below compiles
fine with my gcc 3.2.2 with
On 01/05/2006 01:51 PM, Ruediger Pluem wrote:
[..cut..]
I finally merged all the commits done to the trunk on this issue
r354628
r354636
r357461
r357519
r365374
r366181
into one patch that works with 2.2.x. From my current point of view all
aspects of this issue should be considered by this
Matthias Behrens wrote:
i am running a cgi-serverfarm behind an apache webserver with mod_rewrite /
mod_proxy
one cgi is supposed to send a progress bar using serverpush
everytime the programm completes 5% of its work, it sends further html-code which lets the bar grow
u can all test this
On Sat, 2005-12-31 at 13:47, Brian J. France wrote:
On Dec 31, 2005, at 1:23 PM, Rian Hunter wrote:
Any comments, ideas and criticisms are highly welcomed! Thanks!
Any changes on how recipients and queue/deliver is handled?
I started implementing my proposal from a while back and got
On 01/05/2006 09:04 PM, Graham Leggett wrote:
Matthias Behrens wrote:
[..cut..]
This is an interesting problem, but definitely worth looking into fixing.
The logic in mod_proxy_http.c of 2.2.x already tries to address this issue by
flushing the data if no more data is available from the
On 01/05/2006 05:24 PM, Joe Orton wrote:
On Thu, Jan 05, 2006 at 08:14:58AM -0800, Justin Erenkrantz wrote:
I do note that the 2.0 code says:
/* The client has aborted, but the request was successful. We
* will report success, and leave it to the access and error
Ruediger Pluem wrote:
The logic in mod_proxy_http.c of 2.2.x already tries to address this issue by
flushing the data if no more data is available from the backend right now:
apr_read_type_e mode = APR_NONBLOCK_READ;
int finish = FALSE;
do {
On 01/05/2006 10:25 PM, Graham Leggett wrote:
Ruediger Pluem wrote:
[..cut..]
Anyway, it does not work as expected, as it seems that the condition
(APR_STATUS_IS_EAGAIN(rv)
|| (rv == APR_SUCCESS
APR_BRIGADE_EMPTY(bb))) {
never gets true.
I think this if
Ruediger Pluem wrote:
Anyway, it does not work as expected, as it seems that the condition
(APR_STATUS_IS_EAGAIN(rv)
|| (rv == APR_SUCCESS
APR_BRIGADE_EMPTY(bb))) {
never gets true.
Looking deeper into this, if the above was never true, then the loop
would spin
On 01/05/2006 11:27 PM, Graham Leggett wrote:
Ruediger Pluem wrote:
[..cut..]
Looking deeper into this, if the above was never true, then the loop
would spin resulting in 100% processor usage for this process/thread
while the download was running.
Are you 100% sure this is never called?
On Jan 5, 2006, at 4:49 AM, [EMAIL PROTECTED] wrote:
+In order to handle empty boundaries, we'll look for the
+boundary plus the \n. */
+
+ boundary_line = apr_pstrcat(p, --, mail-boundary, \n, NULL);
/* The start boundary */
- bound = ap_strstr(mail-body,
Hi,
* Roy T. Fielding [EMAIL PROTECTED] [2006-01-05 16:39:16]:
+boundary_line = apr_pstrcat(p, --, mail-boundary, \n, NULL);
/* The start boundary */
-bound = ap_strstr(mail-body, mail-boundary);
+bound = ap_strstr(mail-body, boundary_line);
That seems a bit risky --
On 1/5/06, Ian Holsman [EMAIL PROTECTED] wrote:
this allows you to pass a 'path' to the fast cgi process
to use:
ProxyPass /forum fcgi-tcp://127.0.0.1:8005/foruX
request
/forum/zx will have a path_info of /foruX/zx
posting it as a patch, as the code is a bit fugly.
The question is, what
29 matches
Mail list logo
