Re: interaction between mod_substitute and mod_proxy
Hi all, I'm a newbie to the development of Apache. It seems that the contents returning from reverse proxy won't be processed by the mod_substitute? I did some tests, in normal case without reverse proxy, the web pages from the Apache itself will be substituted. mod_proxy is implemented as a hook, but mod_substitute as a filter... Is that possible to make them work together? After roughly tracing the code of mod_proxy, it receives the data from the server and sends out the contents to the client directly via apr_socket_send(). Does that imply it doesn't put the data into output filters? That's why they don't work together? If I wanna have the same effect as mod_substitute on mod_proxy, I should modify the code of mod_proxy rather than using mod_substitute? Thanks Best regards, honercek http://www.google.com/profiles/honercek
Re: svn propchange: r953418 - svn:log
On Fri, Jun 11, 2010 at 4:58 PM, wr...@apache.org wrote: Author: wrowe Revision: 953418 Modified property: svn:log Modified: svn:log at Fri Jun 11 20:58:40 2010 -- --- svn:log (original) +++ svn:log Fri Jun 11 20:58:40 2010 @@ -1,2 +1,5 @@ Use APR_STATUS_IS_TIMEUP instead of direct compare to APR_TIMEUP to be more safe on different platforms. + +PR: 49417 +Addresses CVE-2010-2068 Would it be accurate to add the following paragraph? Some folks may be bewildered that the vulnerability affects only certain platforms yet the commit that resolves it modifies platform-independent code. ---cut here--- Note: This commit has an additional, platform-independent change to mark the back-end connection for closing ( backend-close = 1;) That code is not required to resolve CVE-2010-2068 on any platform. ---cut here---
Re: svn propchange: r953418 - svn:log
On 6/14/2010 12:45 PM, Jeff Trawick wrote: On Fri, Jun 11, 2010 at 4:58 PM, wr...@apache.org wrote: Author: wrowe Revision: 953418 Modified property: svn:log Modified: svn:log at Fri Jun 11 20:58:40 2010 -- --- svn:log (original) +++ svn:log Fri Jun 11 20:58:40 2010 @@ -1,2 +1,5 @@ Use APR_STATUS_IS_TIMEUP instead of direct compare to APR_TIMEUP to be more safe on different platforms. + +PR: 49417 +Addresses CVE-2010-2068 Would it be accurate to add the following paragraph? Some folks may be bewildered that the vulnerability affects only certain platforms yet the commit that resolves it modifies platform-independent code. ---cut here--- Note: This commit has an additional, platform-independent change to mark the back-end connection for closing ( backend-close = 1;) That code is not required to resolve CVE-2010-2068 on any platform. ---cut here--- Feel free to add this to the patches/ files as well. +1
Re: Bumping autoconf AC_PREREQ to 2.60?
On Monday 14 June 2010, William A. Rowe Jr. wrote: On 6/13/2010 7:33 AM, Stefan Fritsch wrote: If we want to support autoconf 2.59, it seems much easier to just backport the autoconf macro. And in that way, non-gcc users would benefit as well. Please report back on the licensing of that macro. You are right. Autoconf licensing exception covers only output of Autoconf which the macros are not. Therefore the macros are GPL and cannot be included into httpd. I will instead implement a warning that a newer version of autoconf is recommended.
external links/webring
The asf-wide, site-dev team noticed our webring seems horribly dated, just as the ASF list of 'apache resources' was. We should determine how we might provide external/thirdparty links and under what set of criteria. The immediate question is; what to do with the webring itself? [ ] unplug from the webring [ ] reset/relaunch some webring [ ] leave as-is Preferences please? TIA, Bill
Re: svn commit: r951896 - in /httpd/httpd/trunk/modules/ssl: ssl_engine_io.c ssl_engine_kernel.c
On Wednesday 09 June 2010, Ruediger Pluem wrote:
On 06/09/2010 09:55 PM, Stefan Fritsch wrote:
On Wed, 9 Jun 2010, Ruediger Pluem wrote:
On 06/06/2010 07:01 PM, s...@apache.org wrote:
Author: sf
Date: Sun Jun 6 17:01:29 2010
New Revision: 951896
URL: http://svn.apache.org/viewvc?rev=951896view=rev
Log:
Use new loglevel accessor macros to simplify code
Modified:
httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_
engine_io.c?rev=951896r1=951895r2=951896view=diff
===
===
--- httpd/httpd/trunk/modules/ssl/ssl_engine_io.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_io.c Sun Jun 6
17:01:29 2010
@@ -1015,7 +1015,7 @@ static void ssl_filter_io_shutdown(ssl_f
SSL_smart_shutdown(ssl);
/* and finally log the fact that we've closed the
connection */
-if (mySrvFromConn(c)-loglevel = APLOG_INFO) {
+if (APLOGcinfo(c)) {
IMHO you need to use APLOGinfo(mySrvFromConn(c)) as otherwise
you might choose the base_server
which might not be what mySrvFromConn(c) returns.
I think it is even more complicated than that and it affects many
places in mod_ssl. If c has a loglevel configuration, we should
probably use that. If not, we should use mySrvFromConn(c). But
in both cases, the log message should be tied to the connection,
to ensure that things like the client IP are logged. Maybe we
need a ap_log_scerror that accepts both a server_rec and
conn_rec.
Makes sense.
Done in r954611.
AIUI, c-base_server is the default virtual host for the relevant
IP/port. Without SNI, mySrvFromConn(c) is the same but with SNI,
mySrvFromConn(c) may be a different name-based virtual host with
the same IP/port. So, mySrvFromConn(c) is basically r-server?
Is that correct?
Yes, but a this point of time we may not have a request (yet), so
mySrvFromConn(c) is the same as what r-server will be later
during request processing.
Regards
Rüdiger
Re: Running log_transaction from a pre-cleanup
On Saturday 12 June 2010, Stefan Fritsch wrote: From the blockers section in STATUS: * Running the log_transaction hook from pool cleanup is fubar: http://marc.info/?l=apache-httpd-devm=123910381908293w=1 Shouldn't the log_transaction hook simply be called from a pre- cleanup? After all, a module may create a sub-pool from the request pool at some time and still need that sub-pool in its log_transaction hook. I have changed this in r954590 and it fixed the segfaults for me. Does anyone still see a problem or can I remove that item from the blockers list?
Re: Change FILE/... buckets to close file descriptor on destruction?
On Tuesday 18 May 2010, Stefan Fritsch wrote: On Tuesday 18 May 2010, Joe Orton wrote: On Tue, May 18, 2010 at 09:18:23AM +0200, Stefan Fritsch wrote: On Tue, 18 May 2010, Ruediger Pluem wrote: So if you want to close this fd you IMHO would need to do some refcounting and only close it if no other filebucket still references it. The filebuckets already do refcounting. apr_bucket_shared_destroy(f) in the patch above is only true if the refcount has reached zero. They refcount the number of times the FILE bucket has been split/copied, they don't refcount the number of times the underlying apr_file_t object is used. APR does not seem to be consistent about of whether ownership of the object is passed on when you create a bucket wrapper for that object type; there are no API guarantees or constraints here. From a quick review, PIPE, MMAP, HEAP (kind of) do take ownership, FILE and SOCKET do not. Have you run the perl-framework test suite to see whether this breaks anything? This change does look like it'll break the APR test suite but only because of the way I happened to write one of the buckets tests. It does not cause any breakage in the perl-framework. As you suspected, it does break apr-util's testbuckets test. I will look if I can run the subversion test suite, too. If changing the current behaviour is considered too disruptive, one could also introduce a flag for the cleanup behaviour of FILE buckets, like there is a flag for mmap. IMHO doing the closing in the bucket cleanup is far preferable to doing it anywhere else in the core output filter. From other mail: I found no breakage in subversion 1.6.11's test suite. To get this item from the httpd 2.4 blockers list, we could vote: [ ] change FILE/PIPE/SOCKET bucket in APR to close file descriptor when the last referencing bucket is destroyed [ ] same as above, but only if a new flag is set (like flag for mmap) [ ] don't change APR, work around problem in httpd But I am not sure what introducing a new element in struct apr_bucket_file would mean for ABI compatibility. On the one hand, apr_bucket_file is public, on the other hand, there are functions like apr_bucket_file_create and apr_bucket_file_enable_mmap. Would adding an element at the end be ok for apr-util 1.4, or would that only be possible in 2.0? Cheers, Stefan
Re: Change FILE/... buckets to close file descriptor on destruction?
On 6/14/2010 4:20 PM, Stefan Fritsch wrote: But I am not sure what introducing a new element in struct apr_bucket_file would mean for ABI compatibility. On the one hand, apr_bucket_file is public, on the other hand, there are functions like apr_bucket_file_create and apr_bucket_file_enable_mmap. Would adding an element at the end be ok for apr-util 1.4, or would that only be possible in 2.0? We could create a new apr_bucket_file_closing flavor, but no. You can't alter the public structures until 2.0. I really don't recall why these internals were exposed, but this does demonstrate that might have been a bad idea ;-) As far as changing the structure itself, I wouldn't start creating two ints when it's simple to change can_mmap to a bit flag, likewise 'should be closed'. But you are thinking of marking every bucket for this file with this flag? I'm wondering if this isn't actually a more general problem that would be better solved with a broader hook-on-refcount==0 entity?
Re: external links/webring
On 06/14/2010 09:45 PM, William A. Rowe Jr. wrote: The asf-wide, site-dev team noticed our webring seems horribly dated, just as the ASF list of 'apache resources' was. We should determine how we might provide external/thirdparty links and under what set of criteria. The immediate question is; what to do with the webring itself? [X] unplug from the webring [ ] reset/relaunch some webring [ ] leave as-is Regards Rüdiger
