Re: 2_0_BRANCH tree status
On Thu, 5 Dec 2002 20:11:41 +0100, Sander Striker wrote:
>So many commits lately I'm having trouble keeping track.
>If I were to tag 2_0_44_PRE1 now, would I be leaving
>anything important out (apart from the IPv6 TCP_CORK
>fix)? Is there more reverting/fixing to do on the aaa
>front (Japanese docs)?
The builds of APACHE_2_0_BRANCH & HEAD are both busted right now.
I posted this a couple of days ago:
On Tue, 03 Dec 2002 23:24:46 +1000 (EST), Brian Havard wrote:
>On Fri, 29 Nov 2002 12:09:55 -0800, Wilfredo Sánchez wrote:
>
>> Yuck OK. $< is used for the ApacheCoreOS2.def, though I suppose that
>>only matters for OS/2. I won't touch it.
>
>That should be fine as only gnu make is used to build on OS/2. There's
>another problem though that breaks the OS/2 build & I'm not sure what the
>right fix is. What's happening is that exports.c tries to #include
>"winconfig.h" which it finds in apr-util/xml/expat/lib/winconfig.h which
>fails as that tries to #include windows.h.
>
>I don't think the expat library headers should be included by EXPORT_DIRS,
>I can't see any reason to force all expat functions into the Apache core.
On further investigation it appears the culprit is in configure.in where:
APU_INCLUDEDIR=`$apu_config --includes | sed 's|^.*-I\([[^ ]]*apr[[^ ]]*\).*$|\1|'`
which extracts the LAST -I directory when it needs to extract the first.
My apu-config --include prints:
-I/Apache/httpd-2.0/srclib/apr-util/include
-I/Apache/httpd-2.0/srclib/apr-util/xml/expat/lib
so I get the expat headers which I don't want & I don't get the apr-util
headers which I do want. This fixes it for me:
Index: configure.in
===
RCS file: /home/cvs/httpd-2.0/configure.in,v
retrieving revision 1.236
diff -u -r1.236 configure.in
--- configure.in29 Nov 2002 07:34:20 - 1.236
+++ configure.in3 Dec 2002 12:52:21 -
@@ -100,7 +100,7 @@
APR_ADDTO(LDFLAGS, `$apu_config --ldflags`)
APR_ADDTO(INCLUDES, `$apu_config --includes`)
APU_BINDIR=`$apu_config --bindir`
-APU_INCLUDEDIR=`$apu_config --includes | sed 's|^.*-I\([[^ ]]*apr[[^ ]]*\).*$|\1|'`
+APU_INCLUDEDIR=`$apu_config --includes | sed 's|^ *-I\([[^ ]]*apr[[^ ]]*\).*$|\1|'`
echo $ac_n "${nl}Configuring PCRE regular expression library ...${nl}"
--
__
| Brian Havard | "He is not the messiah! |
| [EMAIL PROTECTED] | He's a very naughty boy!" - Life of Brian |
--
Re: 2_0_BRANCH tree status
* Sander Striker wrote:
> So many commits lately I'm having trouble keeping track.
sorry ;-)
> Is there more reverting/fixing to do on the aaa
> front (Japanese docs)?
I won't touch the japanese files, since I would produce weird results, that
I can't verify.
However, if nobody else does the reversion, simply tag the following using
the same revisions as the 2_0_43 Tag instead of the current versions:
docs/sitemap.xml.ja
docs/sitemap.html.ja.jis
docs/mod/quickreference.html.ja.jis
docs/mod/index.html.ja.jis
docs/mod/mod_auth.xml.ja
docs/mod/mod_auth.html.ja.jis
don't tag:
docs/mod/mod_auth_basic.xml.ja
docs/mod/mod_auth_basic.html.ja.jis
(hope, I've got them all)
nd
--
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join #
[ $japh =~ /{(.)}/] -> [0] => map $_ -> () #André Malo #
=> @japh;# http://www.perlig.de/ #
2_0_BRANCH tree status
Hi, So many commits lately I'm having trouble keeping track. If I were to tag 2_0_44_PRE1 now, would I be leaving anything important out (apart from the IPv6 TCP_CORK fix)? Is there more reverting/fixing to do on the aaa front (Japanese docs)? Thanks, Sander
Re: IPv6 breakage on NetBSD
Jeff Trawick <[EMAIL PROTECTED]> writes: > Unfortunately, I did not apply the patch to APACHE_2_0_BRANCH until > last night. Please update server/listen.c to pick up the fix and > report back. IMHO we shouldn't release 2.0.44 without this issue > resolved. While I'm "sure" the patch fixes it, it would be nice to > hear from you. Yep, this fixes it. Consider this issue resolved. -- Eric Gillespie <*> [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: Should mod_proxy abort when browser aborts?
--On Thursday, December 5, 2002 11:35 AM +0200 "Tikka, Sami" <[EMAIL PROTECTED]> wrote: Should the check for conn->aborted flag be added into proxy_http.c? No, I'd prefer not. The core_output_filter should be returning the error code. The fact that it is returning APR_SUCCESS when there was an error is a bug. We've discussed this before, but I forget what the conclusion was. Jeff or OtherBill, do you remember what we agreed to do? ISTR there was a reason why we just couldn't return the error code from core_output_filter - we had to do something else first then we could fix this bug. -- justin
Re: Linux + TCP_CORK + IPv6 = Broken [PATCH]
On Thu, Dec 05, 2002 at 04:17:53PM +, Joe Orton wrote: > To summarize some off-list dicussion - the kernel guys have said that > using sendfile on IPv6 sockets may trigger bugs in cards which do > hardware TCP checksumming for card/driver/OS combinations which support > that. (since the cards have to know about IPv6, and that probably > doesn't get tested much). Cool :-) Just to point out, IPv6 + sendfile() works fine , IPv6 + sendfile() + TCP_CORK = badness. For me anyway :-) -- [EMAIL PROTECTED]PubKey: [EMAIL PROTECTED] Web: http://devnull.redbrick.dcu.ie/
Re: Linux + TCP_CORK + IPv6 = Broken [PATCH]
To summarize some off-list dicussion - the kernel guys have said that
using sendfile on IPv6 sockets may trigger bugs in cards which do
hardware TCP checksumming for card/driver/OS combinations which support
that. (since the cards have to know about IPv6, and that probably
doesn't get tested much).
Colm confirmed using tcpdump traces that the "missing" response packets
were indeed getting sent with bad checksums. ("tcpdump -vv -s 1500 ip6"
is the magic invocation for the curious)
joe
Re: [PATCH] Re: Broken find usage in server/Makefile.in (HEAD and APACHE_2_0_BRANCH)
* Eric Gillespie ([EMAIL PROTECTED]) wrote : > Eric Gillespie <[EMAIL PROTECTED]> writes: > > > tmp=export_files_unsorted.txt; rm -f $tmp && touch $tmp; for dir in /usr/lo > > cal/apache2/src/include /usr/local/apache2/src/os/S_DIR PR_INCLUDEDIR PU_INCL > > UDEDIR /usr/local/apache2/src/modules/http; do find $dir -maxdepth 1 -type f > > -name '*.h' >> $tmp; done; cat $tmp | sort | uniq > export_files; rm -f $ > > tmp > > find: -maxdepth: unknown option > > *** Error code 1 > > > > This is on NetBSD/i386 1.6. > > No one's biting, eh? Because of that, i tried to fix it myself > and discovered that there is further breakage beyond this. > The correct fix is to revert server/Makefile.in to 1.75 I think. -Thom
[PATCH] Re: Broken find usage in server/Makefile.in (HEAD and APACHE_2_0_BRANCH)
Eric Gillespie <[EMAIL PROTECTED]> writes:
> tmp=export_files_unsorted.txt; rm -f $tmp && touch $tmp; for dir in /usr/lo
> cal/apache2/src/include /usr/local/apache2/src/os/S_DIR PR_INCLUDEDIR PU_INCL
> UDEDIR /usr/local/apache2/src/modules/http; do find $dir -maxdepth 1 -type f
> -name '*.h' >> $tmp; done; cat $tmp | sort | uniq > export_files; rm -f $
> tmp
> find: -maxdepth: unknown option
> *** Error code 1
>
> This is on NetBSD/i386 1.6.
No one's biting, eh? Because of that, i tried to fix it myself
and discovered that there is further breakage beyond this.
I couldn't believe how pointless the find usage was, since it's
depth 1 and a single glob. However, things explode a little
later because the code in configure.in to find APU_INCLUDEDIR is
busted:
0 httpd-2.0% ./srclib/apr-util/apu-config --includes
-I/u/epg/work/apache2/httpd-2.0/srclib/apr-util/include
-I/u/epg/work/apache2/httpd-2.0/srclib/apr-util/xml/expat/lib
0 httpd-2.0% ./srclib/apr-util/apu-config --includes | sed 's|^.*-I\([^ ]*apr[^
]*\).*$|\1|'
/u/epg/work/apache2/httpd-2.0/srclib/apr-util/xml/expat/lib
So here are the fixes:
--- server/Makefile.in.~1.75.2.5.~ Thu Dec 5 07:35:03 2002
+++ server/Makefile.in Thu Dec 5 08:30:30 2002
@@ -47,7 +47,7 @@
tmp=export_files_unsorted.txt; \
rm -f $$tmp && touch $$tmp; \
for dir in $(EXPORT_DIRS); do \
- find $$dir -maxdepth 1 -type f -name '*.h' >> $$tmp; \
+ ls $$dir/*.h >> $$tmp; \
done; \
cat $$tmp | sort | uniq > $@; \
rm -f $$tmp
--- configure.in.~1.232.2.1.~ Thu Dec 5 07:34:57 2002
+++ configure.inThu Dec 5 09:23:47 2002
@@ -100,7 +100,7 @@
APR_ADDTO(LDFLAGS, `$apu_config --ldflags`)
APR_ADDTO(INCLUDES, `$apu_config --includes`)
APU_BINDIR=`$apu_config --bindir`
-APU_INCLUDEDIR=`$apu_config --includes | sed 's|^.*-I\([[^ ]]*apr[[^ ]]*\).*$|\1|'`
+APU_INCLUDEDIR=`$apu_config --includes | awk '{ for (i = 1; i <= NF; i++) { if ($i ~
+/^-I[[^ ]]*apr/ and $i !~ /expat/) { sub("-I", "", $i); print $i } } }'`
echo $ac_n "${nl}Configuring PCRE regular expression library ...${nl}"
--
Eric Gillespie <*> [EMAIL PROTECTED]
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
RE: Linux + TCP_CORK + IPv6 = Broken [PATCH]
Colm MacCárthaigh [mailto:[EMAIL PROTECTED]] wrote: > On Thu, Dec 05, 2002 at 12:58:48PM +, Colm MacCárthaigh wrote: > > I'm using vanilla 2.4.18, from Debian kernel-source-2.4.18 > , one machine > > has the broadcom bcm5700 module, and the the other has the intel > > e1000 module. > > O.k., more testing, I've tried it out on another box, which has > a 3com network card and IDE disks, and it *doesnt* happen there. > > Things the vulnerable machines have in common: > > SCSI hard-disks > Software RAID 1 set-up > GigE cards (bcm5700 , e1000) > Dell (2650, and 1650) > > Things unaffected machine has: > > IDE disks > no RAID > 3c905 network card. I just recompiled the debian's 2.0.43 with --without-sendfile (push it in the args list of debian/rules) and now www.sixxs.net works fully on IPv4/IPv6 and IPv4-SSL and IPv6-SSL. As for the hardware in that box, Linux 2.4.18, Celeron, IDE, ext3 fs's and a: eth0: RealTek RTL8139 Fast Ethernet at 0xd080, 00:10:dc:20:7c:7c, IRQ 11 eth0: Identified 8139 chip type 'RTL-8139B' purgatory.unfix.org has 2.4.18, p100, IDE, ext3 and a Intel and DEC, but IPv6 is tunneled and doesn't have that problem. games.concepts.nl box has 2.4.19-pre5-ac3, Athlon, SCSI, ext3 and a 3c905C, this one doesn't have any problems. I'll be running that first box with --without-sendfile :) If you need extra informations don't mind to speak up. Greets, Jeroen
Re: Linux + TCP_CORK + IPv6 = Broken [PATCH]
On Thu, Dec 05, 2002 at 12:58:48PM +, Colm MacCárthaigh wrote: > I'm using vanilla 2.4.18, from Debian kernel-source-2.4.18 , one machine > has the broadcom bcm5700 module, and the the other has the intel > e1000 module. O.k., more testing, I've tried it out on another box, which has a 3com network card and IDE disks, and it *doesnt* happen there. Things the vulnerable machines have in common: SCSI hard-disks Software RAID 1 set-up GigE cards (bcm5700 , e1000) Dell (2650, and 1650) Things unaffected machine has: IDE disks no RAID 3c905 network card. So unless both the bcm5700 and e1000 driver are affected, it's probably not that. To test if it was the raid stuff, I moved my stuff to a non-RAID scsi partition, and that didnt fix anything. So I think that can be ruled out. I havnt got any idea what's causing it, but bottom line, it looks less and less likely that this is a bug with apache, and more like TCP_CORK + IPv6 is broken on some linux setups. -- [EMAIL PROTECTED]PubKey: [EMAIL PROTECTED] Web: http://devnull.redbrick.dcu.ie/
Re: Linux + TCP_CORK + IPv6 = Broken [PATCH]
On Thu, Dec 05, 2002 at 11:30:29AM +, Joe Orton wrote: > On Thu, Dec 05, 2002 at 10:54:53AM +, Colm MacCárthaigh wrote: > .. > > telnet [v6addr] 80 > > GET / HTTP/1.1 > > Host: madeup.tld > > > > > > Have you verified with tcpdump/ethereal etc that this hang is because > the server is not sending the packets? What does netstat -t show for > this connection? > > That test works fine for me here between two 2.4.18-based boxes - are > you using vanilla unpatched 2.4.18? I'm using vanilla 2.4.18, from Debian kernel-source-2.4.18 , one machine has the broadcom bcm5700 module, and the the other has the intel e1000 module. Just to make doubly sure netstat -t shows tcp 0504 2001:770:18:2:206:5b:80 2001:770:18:1:201:33128 ESTABLISHED ethereal tells me that the first request is happening fine, it sees the GET and then returns the 200. the second request however doesnt do this, it sends 4 HTTP 200's before issueing 2 FIN/ACK's and an RST. I'm seeing the same thing from the client side, but no output in telnet. So it is sending *something*, just a very broken something. -- [EMAIL PROTECTED]PubKey: [EMAIL PROTECTED] Web: http://devnull.redbrick.dcu.ie/
Re: Linux + TCP_CORK + IPv6 = Broken [PATCH]
On Thu, Dec 05, 2002 at 10:54:53AM +, Colm MacCárthaigh wrote: .. > telnet [v6addr] 80 > GET / HTTP/1.1 > Host: madeup.tld > > Have you verified with tcpdump/ethereal etc that this hang is because the server is not sending the packets? What does netstat -t show for this connection? That test works fine for me here between two 2.4.18-based boxes - are you using vanilla unpatched 2.4.18? joe
Re: Linux + TCP_CORK + IPv6 = Broken [PATCH]
On Thu, Dec 05, 2002 at 07:16:02AM +, Joe Orton wrote:
> On Wed, Dec 04, 2002 at 11:38:06PM +, Colm MacCárthaigh wrote:
> > On Wed, Dec 04, 2002 at 11:05:21PM +, Joe Orton wrote:
> > > Colm, can you try running the apr/test/sendfile binary with your
> > > machines?
> >
> > It was one of the first things I tried when I was debugging,
> > unfortunately, it doesnt seem to support IPv6 from the client side
> > at all, I get:
> >
> > colmmacc@byron:~/apr/test$ ./sendfile client blocking orion.ipv6.heanet.ie
> > Creating a test file...
> > apr_sockaddr_info_get()->670005/No address associated with hostname
>
> Oh, sorry, I forgot to mention, you have to change the "family =
> APR_INET" line to "family = APR_INET6" to make it work over IPv6.
O.k., I've done that, and yes it works for me. sendfile.c
creates and deletes the file it sends though, it also only
serves it once, and the bug only appears when you do it twice.
In order to see the bug sendfile.c would have to try and
send the same file down two different sockets. One after
another, and monitor the second one. I patched it to fix
this (patch is below), but it isnt displaying the problem.
There are a few slight differences in what it's doing compared
to httpd though. Firstly, it's the client end that's sending
the file here, which might be relevant.
The way I can reliably reproduce the bug, is :
./configure
make
make install
dd bs=1 count=256 if=/dev/zero of=/usr/local/apache2/htdocs/index.html
/usr/local/apache2/bin/apachectl start
[ go to other machine ]
telnet [v6addr] 80
GET / HTTP/1.1
Host: madeup.tld
telnet [v6addr] 80
GET / HTTP/1.1
Host: madeup.tld
Index: sendfile.c
===
RCS file: /home/cvspublic/apr/test/sendfile.c,v
retrieving revision 1.23
diff -u -r1.23 sendfile.c
--- sendfile.c 20 Nov 2002 03:50:22 - 1.23
+++ sendfile.c 5 Dec 2002 10:40:39 -
@@ -222,9 +222,9 @@
int family;
apr_sockaddr_t *destsa;
-family = APR_INET;
+family = APR_INET6;
apr_setup(&p, &sock, &family);
-create_testfile(p, TESTFILE);
+/* create_testfile(p, TESTFILE); */
rv = apr_file_open(&f, TESTFILE, APR_READ, 0, p);
if (rv != APR_SUCCESS) {
@@ -492,13 +492,13 @@
printf("client: apr_socket_sendfile() worked as expected!\n");
-rv = apr_file_remove(TESTFILE, p);
+/*rv = apr_file_remove(TESTFILE, p);
if (rv != APR_SUCCESS) {
fprintf(stderr, "apr_file_remove()->%d/%s\n",
rv,
apr_strerror(rv, buf, sizeof buf));
exit(1);
-}
+} */
return 0;
}
@@ -752,6 +752,8 @@
host = argv[3];
}
if (!strcmp(argv[2], "blocking")) {
+ client(BLK, host);
+ sleep(10);
return client(BLK, host);
}
else if (!strcmp(argv[2], "timeout")) {
--
[EMAIL PROTECTED]PubKey: [EMAIL PROTECTED]
Web: http://devnull.redbrick.dcu.ie/
Should mod_proxy abort when browser aborts?
Another thing I have been oogling is proxy_http.c line 946 where the HTTP
response is passed to proxy output filters:
if (ap_pass_brigade(r->output_filters, bb) != APR_SUCCESS) {
/* Ack! Phbtt! Die! User aborted! */
p_conn->close = 1; /* this causes socket close below */
finish = TRUE;
}
It seems to me that core_output_filter always returns APR_SUCCESS, even if it
detects that the socket has been closed by the browser, which means that the
proxy will happily download and send all of the HTTP response even if there
is no-one to send it to.
I am tinkering with a small proxy output filter and I'm working around the
problem like this: (code in my output filter)
rv = ap_pass_brigade(f->next, bb);
if (!APR_STATUS_IS_SUCCESS(rv) || f->c->aborted) {
ap_log_rerror();
return AP_FILTER_ERROR;
}
return rv;
Should the check for conn->aborted flag be added into proxy_http.c? I think
it should. It would of course prevent the proxy from continuing to download
into the cache after the browser has aborted, even if this was the desired
behaviour. But is that really a good feature anyway? Isn't it too easy to
overload the proxy by a malicious or ignorant user by starting to download a
big file and aborting and repeating this a few hundred times?
--
Sami Tikka, senior software engineer, F-Secure Corporation
tel: +358 9 2520 5115, fax: +358 9 2520 5015
http://www.F-Secure.com
F-Secure: Securing the Mobile Enterprise
Re: STATUS mailings for stable httpd 2.0
> Justin wrote ( RE: Apache STATUS files )... > > Oh, I hate to get more email that I just delete as soon as it comes in > > Does anyone actually read these things though? Yes.
