Use of brigade_split...
First, let me say that apr_brigade_split is evil.
It is used in several filters to break up input, or temporarily store
some buckets. The problem is that it allocates a new brigade, commonly
out of the request pool.
This is fine, if you only call it once, but for streaming filters, where
your filter might be called hundreds of times, it will leak a brigade
every time.
This was the cause of the memory 'leak' in PR 33382 (Proxying Windows
Media Player Streams). With just a quick look in the source, I believe
there is also a bug in the mod_deflate input filter. Consider the code
in mod_deflate.c line 813:
if (!APR_BRIGADE_EMPTY(ctx-proc_bb)) {
apr_bucket_brigade *newbb;
/* May return APR_INCOMPLETE which is fine by us. */
apr_brigade_partition(ctx-proc_bb, readbytes, bkt);
newbb = apr_brigade_split(ctx-proc_bb, bkt);
APR_BRIGADE_CONCAT(bb, ctx-proc_bb);
APR_BRIGADE_CONCAT(ctx-proc_bb, newbb);
}
While this code works, it does not provide any reuse of the bucket
brigade *newbb. The inflate filter will effectively leak one brigade
every time it is called. To fix it, a brigade should be added to the
filter context, and recycled. Instead of using brigade_split, the
buckets should be moved to this persistent brigade.
I count 11 [1] uses of apr_brigade_split in the trunk source tree. If
anyone has some spare time, I believe many of them will reveal that they
have the possibility to leak too. I will try to investigate them all
sooner or later, but some help on this hunt would be nice :)
-Paul
[1]
./modules/filters/mod_deflate.c:819
./modules/http/chunk_filter.c:89
./server/core_filters.c:187
./server/core_filters.c:627
./server/core_filters.c:644
./server/core_filters.c:661
./server/core_filters.c:677
./server/core_filters.c:697
./server/core_filters.c:762
./server/mpm/experimental/perchild/perchild.c:1572
./server/protocol.c:1201
Re: Use of brigade_split...
On Fri, Feb 18, 2005 at 01:12:52AM -0800, Paul Querna wrote: First, let me say that apr_brigade_split is evil. Specifically the combination of apr_brigade_split() and an apr_brigade_destroy() which is a noop, yes; #23567 is another example of a leak caused by this. I'd also concluded that eliminating use of apr_brigade_split() was probably the easiest way out of this hole, it's still fairly disruptive though... joe
Apache on AS/400 (OS400)
Hi. I'm developing an application using APR on OS400 (V5R3M0). The system came with Apache 2 and APR preinstalled. However there is no APR-UTILS. As I know Apache needs also APR-UTILS to compile (e.g. MD5, LDAP, ... support) - so is APR-UTILS available for OS400? I checked the Apache httpd sources and found an 'os400' in Autoconf scripts. How is Apache compiled on OS400? as I know there is no Autoconf available for OS400 - am I wrong? I will appreciate any hints, sugestions,... ;) Regards, Dezo
Re: Use of brigade_split...
On Fri, 18 Feb 2005, Paul Querna wrote: First, let me say that apr_brigade_split is evil. It is used in several filters to break up input, or temporarily store some buckets. The problem is that it allocates a new brigade, commonly out of the request pool. Feel free to write a variant that (also) takes as a parameter the brigade into which to split the second half. :)
Retrieving address via remote_ip
Hi,
I am seeking some assistance in tracking down a problem with building
Apache 2.0.53 + mod_perl2.0.0-RC4 under a FreeBSD 5.3 jailed
environment using gcc 3.4.2 and perl 5.8.6.
One of the mod_perl tests is failing because it is getting a different
remote_ip address than the address being reported by result of
c-remote_ip. Apache's method is getting the real ip address whereas
mod_perl is getting the loopback address.
Both of these are correct but I need to figure out how to get them to
match. I tried looking through the httpd source files but am not a C
programmer and did not have much luck finding the section where
remote_ip is set. Could someone give me a hand?
FYI, this is the code that mod_perl is using to determine the remote ip
(from mod_perl-2.0.0-RC4/Apache-Test/lib/Apache/TestConfig.pm):
sub our_remote_addr {
my $self = shift;
my $name = $self-default_servername;
my $iaddr = (gethostbyname($name))[-1];
unless (defined $iaddr) {
error Can't resolve host: '$name' (check /etc/hosts);
exit 1;
}
$remote_addr ||= Socket::inet_ntoa($iaddr);
}
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.com
Re: Apache on AS/400 (OS400)
Apache2 on iSeries is built from AIX via cross compiler :) I asked many time to Rochester Labs for autoconf/automake port to iSeries but no success ,( On Fri, 18 Feb 2005 11:00:34 +0100 (GMT-1), Damir Dezeljin [EMAIL PROTECTED] wrote: Hi. I'm developing an application using APR on OS400 (V5R3M0). The system came with Apache 2 and APR preinstalled. However there is no APR-UTILS. As I know Apache needs also APR-UTILS to compile (e.g. MD5, LDAP, ... support) - so is APR-UTILS available for OS400? I checked the Apache httpd sources and found an 'os400' in Autoconf scripts. How is Apache compiled on OS400? as I know there is no Autoconf available for OS400 - am I wrong? I will appreciate any hints, sugestions,... ;) Regards, Dezo
Problem with redirections
[Please CC: me on reply, I'm not subscribed to the list.] Hi, sometimes there seems to be a problem with the interoperation of the web browser retawq (http://retawq.sourceforge.net/) and the Apache httpd - the httpd sends a redirection response pointing back to the original request URI, which would cause an infinite loop of redirections. For illustration, here are two request/response examples: --- Example 1 (https://sourceforge.net) --- GET / HTTP/1.0 Host: sourceforge.net:443 User-Agent: retawq/0.2.6 [en] (text, tls; Linux) Accept: */* Accept-Language: en Accept-Charset: iso-8859-1 HTTP/1.1 302 Found Date: Sat, 19 Feb 2005 00:37:18 GMT Server: Apache/1.3.31 (Unix) PHP/4.3.9 mod_ssl/2.8.19 OpenSSL/0.9.7a X-Powered-By: PHP/4.3.9 Location: https://sourceforge.net/index.php Connection: close Content-Type: text/html GET /index.php HTTP/1.0 Host: sourceforge.net:443 User-Agent: retawq/0.2.6 [en] (text, tls; Linux) Accept: */* Accept-Language: en Accept-Charset: iso-8859-1 HTTP/1.1 302 Found Date: Sat, 19 Feb 2005 00:37:20 GMT Server: Apache/1.3.31 (Unix) PHP/4.3.9 mod_ssl/2.8.19 OpenSSL/0.9.7a X-Powered-By: PHP/4.3.9 Location: https://sourceforge.net/index.php Connection: close Content-Type: text/html --- Example 2 (http://www.sciencedaily.com/news/summaries.htm) --- GET /news/summaries.htm HTTP/1.0 Host: www.sciencedaily.com:80 User-Agent: retawq/0.2.6 [en] (text, tls; Linux) Accept: */* Accept-Language: en Accept-Charset: iso-8859-1 HTTP/1.1 302 Found Date: Sat, 19 Feb 2005 00:39:58 GMT Server: Apache/1.3.33 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.10 FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7a Location: http://www.sciencedaily.com/news/summaries.htm Connection: close Content-Type: text/html; charset=iso-8859-1 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE302 Found/TITLE /HEADBODY H1Found/H1 The document has moved A HREF=http://www.sciencedaily.com/news/summaries.htm;here/A.P HR ADDRESSApache/1.3.33 Server at www.sciencedaily.com Port 80/ADDRESS /BODY/HTML - On the one hand, this might be retawq-specific because I didn't see it with any other browser. On the other hand, I saw it only on Apache httpd servers and think that the HTTP specification explicitly forbids a redirection to the original URI; quote from RFC2616, 14.30: The Location response-header field is used to redirect the recipient to a location *other* than the Request-URI...; so maybe the httpd should make sure that the new URI is different from the original one and generate an error otherwise. A quick search for redirect in the CHANGES file of the current httpd 2.0.53 doesn't indicate that this problem might have been fixed for more recent versions than those in the examples. The most related changes I could find were in 2.0.32 and 2.0.28, but the descriptions are about different problems. So there are two questions: Can/will you solve the problem inside httpd somehow? And how could I change the request header to avoid the problem with existing httpd versions? I tried already several changes, but none of them made it work. Thanks in advance, Arne -- www.arne-thomassen.de
Re: Problem with redirections
On Feb 18, 2005, at 4:51 PM, Arne Thomassen wrote: sometimes there seems to be a problem with the interoperation of the web browser retawq (http://retawq.sourceforge.net/) and the Apache httpd - the httpd sends a redirection response pointing back to the original request URI, which would cause an infinite loop of redirections. I just tried it with telnet and can confirm the redirects, though note that the redirect does not happen if you exclude the :80 or :443 port information from Host. It would appear that those sites have been configured to canonicalize the URI used for access, and thus are directing your client not to include the port info in Host. RFC 2616 section 14.23 Host: The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource (generally an HTTP URL, as described in section 3.2.2). The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. Thus, your client is not HTTP-compliant. Also, you should be sending HTTP/1.1 requests, not HTTP/1.0. So there are two questions: Can/will you solve the problem inside httpd somehow? No. And how could I change the request header to avoid the problem with existing httpd versions? Yes, don't add the port to Host unless it was present in the URI. Cheers, Roy T. Fieldinghttp://roy.gbiv.com/ Chief Scientist, Day Software http://www.day.com/
Re: Retrieving address via remote_ip
William McKee wrote: Hi, I am seeking some assistance in tracking down a problem with building Apache 2.0.53 + mod_perl2.0.0-RC4 under a FreeBSD 5.3 jailed environment using gcc 3.4.2 and perl 5.8.6. One of the mod_perl tests is failing because it is getting a different remote_ip address than the address being reported by result of c-remote_ip. Apache's method is getting the real ip address whereas mod_perl is getting the loopback address. It has nothing to do with mod_perl, William. It's Apache-Test that you are after, which is used to test mod_perl. Both of these are correct but I need to figure out how to get them to match. I tried looking through the httpd source files but am not a C programmer and did not have much luck finding the section where remote_ip is set. Could someone give me a hand? it's set in server/core.c: apr_sockaddr_ip_get(c-remote_ip, c-remote_addr); it obtains this information from the live socket connected to a client, whereas Apache-Test tries to resolve the hostname of your machine since at the time when it sets this value there is no connection yet. So as I've replied at the modperl list, you want to figure out how to make Apache-Test report the same value as if it had a live connection from the same machine. If you want to discuss how this can be done, let's do that on the test-dev list where this discussion belongs. Thanks. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: svn commit: r154340 - httpd/httpd/trunk/Makefile.win
On Fri, Feb 18, 2005 at 08:32:07PM -, [EMAIL PROTECTED] wrote: Modified: httpd/httpd/trunk/Makefile.win URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/Makefile.win?view=diffr1=154339r2=154340 == --- httpd/httpd/trunk/Makefile.win (original) +++ httpd/httpd/trunk/Makefile.win Fri Feb 18 12:32:05 2005 @@ -104,7 +104,7 @@ !ENDIF !IF $(INSTDIR) == -INSTDIR=\Apache21 +INSTDIR=g:\built\httpd-2.1-$(SHORT) !ENDIF !IF $(SERVERNAME) == SERVERNAME=localhost Surely, this chunk shouldn't have sneaked in, right? -- justin
