Stas Bekman wrote:
Was httpd and the mod_test_rwrite.so module compiled with the same compiler?
i presume so, since i just built and installed the server and the
framework used the resulting apxs to build its module. but just
to make sure, let me rung through it all again.
one thing that's
Stas Bekman wrote:
Was httpd and the mod_test_rwrite.so module compiled with the same compiler?
just went through and reconfigured the server build, built it, installed
it, cleaned out the .so files in the framework tree, and re-ran
t/TEST -{stop,clean,configure) and then t/TEST . same
Rodent of Unusual Size wrote:
Stas Bekman wrote:
Was httpd and the mod_test_rwrite.so module compiled with the same compiler?
just went through and reconfigured the server build, built it, installed
it, cleaned out the .so files in the framework tree, and re-ran
t/TEST -{stop,clean,configure) and
Stas Bekman wrote:
just went through and reconfigured the server build, built it, installed
it, cleaned out the .so files in the framework tree, and re-ran
t/TEST -{stop,clean,configure) and then t/TEST . same results.
it doesn't mean that the compiler and the same compile options were
Rodent of Unusual Size wrote:
-bI:/home/coar/web/server/libexec/httpd.exp -lc -o mod_test_rwrite.so
mod_test_rwrite.o
ld: 0711-244 ERROR: No csects or exported symbols have been saved.
apxs:Break: Command failed with rc=8
make: 1254-004 The error code from the last command is 1.
the options are
the same sources configured the same way on linux runs fine, but
on aix i get:
/home/coar/web/server/bin/httpd -d /home/coar/ibm/testpak/perl-framework/t -f
/home/coar/ibm/testpak/perl-framework/t/conf/httpd.conf -DAPACHE1
using Apache/1.3.30-dev
waiting 60 seconds for server to start: .Syntax
On Sun, 29 Feb 2004, Justin Erenkrantz wrote:
--On Sunday, February 29, 2004 4:06 PM -0400 Marc G. Fournier
[EMAIL PROTECTED] wrote:
k, if I'm understanding what you are saying, how do you test something
like that in a way that you can debug it? What I'm reading is that if I
sent two
Hi,
Question: Can we use the environment variables setup by mod_ssl in the
RewriteCond directive ?
I believe there's some inconsistency there - the SSL environment variables are setup
in the r-subprocess_env during the hook_fixup phase, where as the RewriteCond
evaluates/expands the
BTW, I forgot to mention that RewriteCond with SSL variables work if (1)
ssl_hook_Translate is APR_HOOK_FIRST and (2) ssl_hook_Fixup logic is transferred to
ssl_hook_Translate.
I know it's a hack - do you think my config is not setup correctly or is the logic
wrong ?
-Madhu
-Original
in 2.0 - Connection output filters don't recieve the EOS bucket when the
request method is HEAD. This breaks the idiom of flushing any stored data when
the eos bucket is seen. And some filters could be broken because of that.
A typical response filter sees this for the following 3 brigades for
Stas Bekman wrote:
If I'm inside an input connection filter and want to be able to tell one
HTTP request from another what should I do? Counting Content-length is
ineffective, and a won't work if C-L header is wrong.
I can tell the end of HTTP headers section from the request body, by
matching
It'd be very helpful if Apache provided methods to query various in and out
stream processing events to make filters more efficient. The events I can
think at the moment are:
- end of HTTP input headers
- end of HTTP input body
- end of HTTP response headers
- end of HTTP response body
only the
* Stas Bekman [EMAIL PROTECTED] wrote:
Ideally the connection record could have the following entries:
done_with_input_headers
done_with_input_body
done_with_output_headers
done_with_output_body
no other comments atm, but this isn't really ideal. The connection does not
know anything
* Stas Bekman [EMAIL PROTECTED] wrote:
in 2.0 - Connection output filters don't recieve the EOS bucket when the
request method is HEAD. This breaks the idiom of flushing any stored data
when the eos bucket is seen. And some filters could be broken because of
that.
I believe that is because
André Malo wrote:
* Stas Bekman [EMAIL PROTECTED] wrote:
Ideally the connection record could have the following entries:
done_with_input_headers
done_with_input_body
done_with_output_headers
done_with_output_body
no other comments atm, but this isn't really ideal. The connection does not
know
André Malo wrote:
* Stas Bekman [EMAIL PROTECTED] wrote:
in 2.0 - Connection output filters don't recieve the EOS bucket when the
request method is HEAD. This breaks the idiom of flushing any stored data
when the eos bucket is seen. And some filters could be broken because of
that.
I believe
--On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman [EMAIL PROTECTED] wrote:
It'd be very helpful if Apache provided methods to query various in and out
stream processing events to make filters more efficient. The events I can
think at the moment are:
...
- end of HTTP input headers
I'm not sure
--On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman [EMAIL PROTECTED] wrote:
Answering my own question, the solution is to use conn-keepalives counter
which is incremented at the end of each request. By storing the previous
count and comparing with the current count one can tell when a new
--On Monday, March 1, 2004 9:55 PM -0800 Stas Bekman [EMAIL PROTECTED] wrote:
I see that with a non-broken handler which sends the response body
unconditionally. The output I've posted in my original email is all that's
seen by an output connection filter.
Why is ap_finalize_request_protocol not
--On Monday, March 1, 2004 11:37 AM -0400 Marc G. Fournier [EMAIL PROTECTED]
wrote:
so I've effectively 'pounded' the server, followed by a telnet session to
the same server doing a 'GET /' and it returned right away:
See below, I think you only have one worker process running. You need
Justin Erenkrantz wrote:
--On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman [EMAIL PROTECTED]
wrote:
It'd be very helpful if Apache provided methods to query various in
and out
stream processing events to make filters more efficient. The events I can
think at the moment are:
...
- end of
Justin Erenkrantz wrote:
--On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman [EMAIL PROTECTED]
wrote:
Answering my own question, the solution is to use conn-keepalives
counter
which is incremented at the end of each request. By storing the previous
count and comparing with the current count
Justin Erenkrantz wrote:
--On Monday, March 1, 2004 9:55 PM -0800 Stas Bekman [EMAIL PROTECTED]
wrote:
I see that with a non-broken handler which sends the response body
unconditionally. The output I've posted in my original email is all
that's
seen by an output connection filter.
Why is
* Stas Bekman [EMAIL PROTECTED] wrote:
Why should a connection-level filter know about HTTP requests? --
justin
Because that's the only way to write a filter that processes HTTP headers
only.
Hmm. FTPYPE_PROTOCOL (sp?) is for such a purpose. If it's no applicable,
we'd need to fix
There must be some simple explanation, but this is very annoying as 'cvs up'
in httpd-2.0 keeps on colliding at these files:
M modules/ssl/ssl_expr_parse.c
M modules/ssl/ssl_expr_parse.h
M modules/ssl/ssl_expr_scan.c
I never touch anything under httpd-2.0/modules/ssl. But the build process
Andr Malo wrote:
* Stas Bekman [EMAIL PROTECTED] wrote:
Why should a connection-level filter know about HTTP requests? --
justin
Because that's the only way to write a filter that processes HTTP headers
only.
Hmm. FTPYPE_PROTOCOL (sp?) is for such a purpose. If it's no applicable,
we'd need
26 matches
Mail list logo
