Re: ap_calculate_scoreboard_Size problem ?
No, it was another bug in the apr_shm where reqsize was passed rather than the physical size (including overhead) so we ended up with a shm that was a wee bit small. Already patched, I believe. Bill - Original Message - From: "Ian Holsman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 06, 2002 11:44 PM Subject: ap_calculate_scoreboard_Size problem ? > one of the developer's over here stumbled on this error. > could this be similiar to the APR_initalize fixed earlier? > > BTW.. this is 31 + justin's patches from his website I think. > > this may be fixed in the most recent build of .31, but... > looks like ap_calculate_scoreboard_size() is 4 bytes off. > > Purify instrumented /home/ronr/.httpd-2_0_31/bin/httpd.pure (pid > 2251, forked from pid 2193) > IPW: Invalid pointer write: >* This is occurring while in: > memset [rtlib.o] > ap_create_scoreboard [scoreboard.c:264] > ap_run_pre_mpm [scoreboard.c:103] > ap_mpm_run [worker.c:1345] > main [main.c:498] > _start [crt1.o] >* Writing 213256 bytes to 0xfb660004 between the heap and the stack > (4 bytes at 0xfb694108 illegal). > > >
ap_calculate_scoreboard_Size problem ?
one of the developer's over here stumbled on this error. could this be similiar to the APR_initalize fixed earlier? BTW.. this is 31 + justin's patches from his website I think. this may be fixed in the most recent build of .31, but... looks like ap_calculate_scoreboard_size() is 4 bytes off. Purify instrumented /home/ronr/.httpd-2_0_31/bin/httpd.pure (pid 2251, forked from pid 2193) IPW: Invalid pointer write: * This is occurring while in: memset [rtlib.o] ap_create_scoreboard [scoreboard.c:264] ap_run_pre_mpm [scoreboard.c:103] ap_mpm_run [worker.c:1345] main [main.c:498] _start [crt1.o] * Writing 213256 bytes to 0xfb660004 between the heap and the stack (4 bytes at 0xfb694108 illegal).
[STATUS] (httpd-2.0) Wed Feb 6 23:45:07 EST 2002
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2002/02/06 22:52:15 $] Release: 2.0.32 : in development 2.0.31 : rolled Feburary 1, 2002. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS CURRENT RELEASE NOTES: * Proposed BETA possibilities 31 + fixes for all resolved problems and call it 32 (instead of HEAD) See: http://www.apache.org/~jerenkrantz/httpd-2.0.jre.patch +1: trawick, Justin, Ian +0: -1: * 31 BETA STATUS: running on Daedalus since 02-Feb-2002 7:58 PST (need 3 days) Compiles on : AIX 4.3, Solaris, FreeBSD 3.4 & 4.5, Win32, Linux 2.2 & 2.4, HPUX Broken on: Win32 [no error logging within service, other bugs] for beta +1 : Aaron +0 : Lars, Justin, trawick -0 : OtherBill -1 : BillS, gregames, BrianP, Jim bumps since original tag: * mod-dir patch * scoreboard x2 : 1 to fix gracefull restarts 1 to fix netware * win32/locks.c : to fix mod_rewrite on win32 problems with v31: * libtool/binbuild on AIX -- possible addition of patched binbuild.sh to 31-beta roll +1: Ian, Justin +0: -1: Jeff says: We can't do anything about libtool since AIX needs a version that won't work on some platforms. Handle this in the README. The binbuild issue isn't AIX. It is something that could happen anywhere that the binbuild-er has their own expat. Handle this by patching binbuild.sh for a beta roll or putting a patch in the README for use by people who want to do binbuild but have expat installed locally. gregames: why can't we roll a second tarball with the appropriate libtool version? doesn't Darwin need it as well as AIX? * erroneous check in an AP_DEBUG_ASSERT() call. Only happens in maintainer mode. Fixed in modules/http/http_protocol.c revision 1.391 * seg faults in core_input_filter when the client goes away before any POST body bytes are received. Jeff committed a fix with server/core.c revision 1.144. Justin committed a fix with server/protocol.c revision 1.78 (server/protocol.c revision 1.81 demotes a potentially annoying error message) * FirstBill reports problem [re]starting as-a-service, shared score is suspect. OtherBill is investigating... has found . created restart and shutdown events, only restart survived initialization on XP, although breaking into the debugger interferes with reproducing the bug. Perhaps in FirstBill's example _restart didn't survive. . Scoreboard appears irrelevant to the problem. . This looks like handle corruption in NT/XP . Args are not initialized correctly when the -k install is given. OtherBill will not create Win32 binaries due to this bug. * mod_auth_dbm can't open a Berkeley DB password file on Unix Justin postulates that this might be related to the fact that mod_auth_dbm wasn't using apr-util. See modules/aaa/mod_auth_dbm.c revision 1.42 and module/aaa/config.m4 revision 1.54. Also, Free
[STATUS] (apache-1.3) Wed Feb 6 23:45:04 EST 2002
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2002/02/06 14:54:52 $] Release: 1.3.24-dev: In development. Jim proposes to T&R around Feb 15 because of the Solaris pthread mutex fix. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the "first minutes" due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at "last minute" due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19. Announced and released. 1.3.0: Tagged and rolled on June 1. Announced and released on the 6th. 2.0 : In alpha development, see httpd-2.0 repository RELEASE SHOWSTOPPERS: RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: <[EMAIL PROTECTED]> Status: * Dean's "unescaping hell" (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: <[EMAIL PROTECTED]> Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-"server" pointer when being dereferenced by invoking "httpd -S". Message-ID: <[EMAIL PROTECTED]> Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: <[EMAIL PROTECTED]> Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker <[EMAIL PROTECTED]> to more fully close some segfault potential. Message-ID: Status: Jim +1 (for 1.3.19), Martin +0 * Patch from "C. Bottelier" <[EMAIL PROTECTED]> to run Apache without daemonizing the parent process. PR#7040 Status: fanf +1 (except it needs docs) * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: <[EMAIL PROTECTED]> Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: <[EMAIL PROTECTED]> Status: Martin +1(concept) * Jayaram's patch (10/27/99) for changes to mod_autoindex Problem 1: AddIcon (,) ^^DIRECTORY^^ and AddIcon (,) ^^BLANKICON^^ should be able to set the alternate text and icon file for any directory/blankicon in a directory listing. This was not happening because the alternate text for ^^DIRECTORY^^ and ^^BLANKICON^^ were hardcoded to "DIR" and " " respectively. Status: resolved in Apache 2.0 Problem 2: - IndexIgnore should hide the files with this file- extension in directory listings. This was NOT happening because the total filename was being compared with the file-extension. Status: Martin +1(untested), Ken +1(untested) *
Re: Current HEAD on Win32
I just added a Sleep(100) call right after the message that the 'child process is running' message in ap_mpm_run. This resulted in 9 of 10 successful restarts when using the windows service manager. I was only getting 2-3 prior to that. I know it's not a valid fix, but it seems that Win can start the child process in such a way that the child is reading from the parent's pipes be fore the data is there. Does that make sense? William A. Rowe, Jr. wrote: >From: "Sebastian Bergmann" <[EMAIL PROTECTED]> >Sent: Wednesday, February 06, 2002 12:35 AM > > >> (This posting maybe a dupe, I hope it's not) >> > >Nope. > >Win32 is borked right now... I'm following in rbb's footsteps and in >the process of normalizing where things happen in the mpm, fixing it's >assorted messages, and getting it to work, from the command line and >from a service. > >It's crufty and taking a while, might be a few hours before all is very >well again. >
Re: mod_autoindex icons wrong?
"William A. Rowe, Jr." wrote: > > From: "Justin Erenkrantz" <[EMAIL PROTECTED]> > Sent: Wednesday, February 06, 2002 3:54 PM > > > Anyone have any details on: > > > > * mod_autoindex displays the wrong icon for subdirectories on Unix > > > > I'd like to see it fixed in 2.0.32, but I don't know the > > details. -- justin > > mod_dir is now a fixup. Ergo the ap_process_request_internal will take > a DIR dirent, passed to ap_sub_req_lookup_dirent(), and transform it to > the actual resource that would be served. > > So if a module used the SSI include virtual="/manual/", it would include > the /manual/index.html body. > > That causes problems for mod_autoindex, alone. mod_autoindex looks at the > subrequest's result - not to determine it's content - but to decide it is > a directory. That's [sort of] lame - and I patched the server to test the > original dirent.filetype instead for the icon test. Con you provide an example of a URL that is failing with current HEAD? I'm having a hard time parsing what you think is broken. Greg
JRE_1 Tagged...
After talking with Ryan for a bit on IRC, he convinced me that the pre_connection change is good and should be included in our next release. If not, we'd release with a hook API we know is bogus. I looked at the diffs between APACHE_2_0_31 and HEAD and I'm fairly confident we're not going to get majorly screwed if we take in the rest of the changes. So, I've taken HEAD as of right now and tagged it as JRE_1. This should encapsulate all of the changes we've made to get a stable build on daedalus. If there are more segfaults or problems, I'll adjust my tag accordingly. I'd like to wait on doing a roll for JRE_1 for Win32 to become functional. In my eyes as RM, this is a showstoper. Disagree? Start your own tree - this is a showstopper for me. I won't roll without it serving pages. It hurts that I can't help out since I don't use Win32, but so it goes. I'll try to track all commits that happen until Win32 becomes stable and judge if they are worthy of bumping the tag on them. -- justin
Re: 1.3.23 msi doesn't install apxs?
From: "Rodent of Unusual Size" <[EMAIL PROTECTED]> Sent: Wednesday, February 06, 2002 8:43 PM > OtherBill, didn't you say that apxs works on Windows > for 1.2? Shouldn't the 'full' MSI install include it? For 1.3.20 or so and on, yes it does work. However, to install it, we would need to 'rewrite' the apxs file to point at the appropriate paths. We do this now with a bit of awk code twords the end of the src/Makefile.win build script, for developers. If you wanted to install for end-users [presuming they even had msvc installed] you would need to change the awk scripts that run as part of the msi installer. Those can be found in the httpd-win32-msi repository. I rolled the two scripts (RewriteConf and DuplicateConf, or some such) into a single script for 2.0. The right solution is probably to follow the pattern of that new script for 2.0, and add the rewriting required for apxs.pl. Bill
Re: mod_autoindex icons wrong?
From: "Justin Erenkrantz" <[EMAIL PROTECTED]> Sent: Wednesday, February 06, 2002 3:54 PM > Anyone have any details on: > > * mod_autoindex displays the wrong icon for subdirectories on Unix > > I'd like to see it fixed in 2.0.32, but I don't know the > details. -- justin mod_dir is now a fixup. Ergo the ap_process_request_internal will take a DIR dirent, passed to ap_sub_req_lookup_dirent(), and transform it to the actual resource that would be served. So if a module used the SSI include virtual="/manual/", it would include the /manual/index.html body. That causes problems for mod_autoindex, alone. mod_autoindex looks at the subrequest's result - not to determine it's content - but to decide it is a directory. That's [sort of] lame - and I patched the server to test the original dirent.filetype instead for the icon test. Greg reverted to rr->finfo.filetype, since dirent.filetype wasn't set on unix. He commented that he wants to avoid a stat. If you look at the dir_walk code, we now -skip- the stat if the r->finfo is already set. That means we -can- completely stat the dirent and we won't repeat the stat later. The simple patch is to change APR_FINFO_DIR (_READDIR? I don't recall) into APR_FINFO_MIN | APR_FINFO_NAME in the apr_dir_read call. And change again back to testing the dirent.filetype to decide if we have a dir. Bill
1.3.23 msi doesn't install apxs?
OtherBill, didn't you say that apxs works on Windows for 1.2? Shouldn't the 'full' MSI install include it? -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: Releases, showstoppers, and vetos
From: "Rodent of Unusual Size" <[EMAIL PROTECTED]> Sent: Wednesday, February 06, 2002 3:08 PM > * On 2002-02-06 at 15:59, > William A. Rowe, Jr. <[EMAIL PROTECTED]> excited the electrons to say: > > > > WRONG. You are proposing that one individual may block a release. > > Yes. > > > That is diametrically opposed to the spirit of HTTP. > > Rubbish. I mean, "I disagree." Everything I have ever read on the philosophy of HTTP [as different from other well respected projects] is that no individual can 'hijaak' the project. While vetos sometimes appear that way, a specific veto of a specific change or patch does no such thing. > > We are [now] treating showstoppers in 2.0 as sancrosect. That > > means they can be overridden. > > If they're sacrosanct, then they can't be overridden. No, while they remain in the SHOWSTOPPERS list, those of us discussing the next beta or potential GA are treating them as absolutes. Therefore, they must be downgraded [moved to WE SHOULD DO THIS] or resolved to move forward to GA. The few folks trying to work through that list are individually nailing the bug or problem, or asking the group for an opinion if they are truly showstoppers, and moving them when it's apparent that the group disagrees. Unless, of course, the SHOWSTOPPER identifies a VETO. > > But one individual cannot block the progress of the Apache HTTP > > Project. > > Stopping a release from happening is far from 'blocking the progress > of the project.' I'm saying that if one of our core developers > thinks the code is so broken it shouldn't be released, then it > shouldn't be released until the issue is resolved to that person's > satisfaction. Again, it's by majority, and 3 +1's to release a product from the ASF. > The problem, of course, is that a code veto can stand forever, > but we cannot allow a release to be blocked that way. So I > guess I'll back down some. :-) > > But only to the point that it needs a majority to demote a > showstopper. I still don't support the idea that 'the RM or > anyone' can do so arbitrarily. And they had them before they did so, I believe.
daedalus is running httpd 2.0.31
...as of Wednesday, 06-Feb-2002 16:35:14 PST. This is with patches for input side seg faults, and for Berkeley DB support to allow authorized bugs.apache.org access to work. The httpd 2.0.29 parent died for the second time today shortly after noon daedalus time, once again triggered by the kernel running out of fd's (ENFILE) and weak httpd accept() error handling. The new build has an uncommitted patch to allow it to survive that condition. I'd like to know for certain that the patch works, get some input on how to fix it the Right Way, and then get serious about tracking down the fd eater. Greg
RE: cvs commit: httpd-2.0 STATUS
> From: "Cliff Woolley" <[EMAIL PROTECTED]> > Sent: Wednesday, February 06, 2002 2:13 PM > > > > On 6 Feb 2002 [EMAIL PROTECTED] wrote: > > > > > +FINAL RELEASE SHOWSTOPPERS: > > > + > > > +* [Ken] Test suite failures: > > > + o worker is also failing some of the 'cgi' subtests > > > + (see http://Source-Zone.Org/Apache/regression/>): > > > +Justin says: "Worker should be fine and passes httpd-test > here. > > > + If you can provide evidence that it can be > reproduced > > > + outside of httpd-test, then it's a > showstopper. I > > > + think it's a perl or a httpd-test problem." > > > +Not a showstopper: Justin > > > + > > > > Sorry I never noticed this in the STATUS file before, but this is > exactly > > the same thing I was seeing on my machine for a while. Turns out if you > > run the tests as root and don't give the apache user rights to the logs > > directory, apache can't create the cgi-log, which causes all those tests > > to fail because they expect that log to be there. Change the directory > > permissions to allow the apache user to write to that directory > (normally > > a very bad thing, I know, but this is just for testing) and it will > > work. Alternatively, we could change the test to put the scriptlog > > someplace else... > > I suspect that forking the cgid process before we setuid, and letting the > cgid > engine setuid itself after it initializes should solve this bug. > > Either that, or the cgi-log needs to be opened in the main server config > so > the cgid deamon doesn't need to do so. The cgi-log is always opened and written by the Apache child that is serving the request. It is closed at the end of the request. It is not meant to be used on a production server, it is strictly a debugging tool. Ryan
Re: UseCanonicalName considered harmful
On Wed, Feb 06, 2002 at 11:01:41PM +0100, Martin Kraemer wrote: > On Wed, Feb 06, 2002 at 08:18:26AM -0800, Aaron Bannert wrote: > > Perhaps we should require the ServerName to have > > a port when there are multiple Listen statements? > > No, that disables the easy (and more useful and intuitive) way of > using the port that the request came in on. My point is that there are times when the incomming port should not be used as the canonical name. I'm simply suggesting that we may wish to avoid confused users by putting in this protection. > Of course, you *can* override it to one (of several Listen ports) or > even to a completely different one (the one used on the firewall's > outside) by using ServerName xx:port As long as it can be overridden then I'm ok with this. -aaron
Re: UseCanonicalName considered harmful
On Wed, Feb 06, 2002 at 08:18:26AM -0800, Aaron Bannert wrote: > Perhaps we should require the ServerName to have > a port when there are multiple Listen statements? No, that disables the easy (and more useful and intuitive) way of using the port that the request came in on. Of course, you *can* override it to one (of several Listen ports) or even to a completely different one (the one used on the firewall's outside) by using ServerName xx:port Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: mod_autoindex icons wrong?
Justin Erenkrantz wrote: > > Anyone have any details on: > > * mod_autoindex displays the wrong icon for subdirectories on Unix > > I'd like to see it fixed in 2.0.32, but I don't know the > details. It's fixed in HEAD last time I checked, with rev 1.93 of mod_autoindex. But OtherBill said that this fix breaks other stuff, and I haven't had a chance to look. Greg
Re: Releases, showstoppers, and vetos
On Wed, Feb 06, 2002 at 01:33:52PM -0800, Roy Fielding wrote: > > I add a showstopper to STATUS. One other person says "-1, that's > > not a showstopper". By my interpretation of the rules, they CANNOT > > demote it from showstopper until there are enough people who would > > vote to release (more +1s than -1s). This means that in order to > > demote it, there would have to be two -1s to offset my +1. > > A showstopper is just an issue! The term "showstopper" has taken on new meaning, and I disagree that it is as simple as an "issue". Having misunderstood and not well defined terms like this is the reason we keep having discussions about release procedures, voting, and showstoppers. Why don't we define these terms once and for all and then work toward some guidelines so we're all on the same page. Here are some terms that I would like defined: issue feature (vs. a bug) showstopper > Damnit guys, if you can't figure this out > I am going to remove the whole category from STATUS as being obviously bad > for your brain cells. That would be an unfortunate situation, since I think making the distinction between critical and non-critical bugs and features is important for group communication. I would veto it if someone tried to merge the categories. > A problem that is a showstopper is simply AN OPINION > that there won't be a majority +1 approval of a release until it is fixed. Votes are expressions of opinions. Showstoppers communicate how those opinions would affect a release. > Obviously, if there is *ANY* debate on whether or not something is a > showstopper, then it doesn't belong in that category -- it doesn't > become a showstopper until it has the effect of stopping the show. > It is just an opinion until someone calls for a vote. No. STATUS is the only place we have to maintain current information about the status of the project. If a showstopper has the potential to stop a release, then STATUS is the correct place to tally the "opinions" (votes) about that particular entry. The final tally of that vote will determine if that issue would stop the show. > The only person who can declare an issue as being a showstopper is the RM, > since they are the one waiting until after the fix is made before creating a > tarball. IMO, this is incorrect. A tarball can only become a [public] release by majority approval. If there are issues that would prevent that approval, then they are by definition showstoppers. > Otherwise, they are free to ignore *any* issue that doesn't > involve an outstanding veto on HEAD. Those are the rules that we've lived > by for a long time now, and there is no way in hell that I'll support the > notion that anyone can stop a release without a formal vote. I'll agree with that. In the end it comes down to one thing: majority approval for releases. Everything else is coordination. -aaron
Re: mod_autoindex icons wrong?
* On 2002-02-06 at 16:52, Justin Erenkrantz <[EMAIL PROTECTED]> excited the electrons to say: > > Anyone have any details on: > > * mod_autoindex displays the wrong icon for subdirectories on Unix > > I'd like to see it fixed in 2.0.32, but I don't know the > details. -- justin I think Greg actually fixed it yesterday. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: Releases, showstoppers, and vetos
* On 2002-02-06 at 16:48, Jim Jagielski <[EMAIL PROTECTED]> excited the electrons to say: > > People should go over the old STATUS files... they were back then > incredibly useful, but now they are bloated and confusing. I've felt this way ever since shortly after they became group-maintained (i.e., went into CVS instead of being privately maintained and mailed by you^H^H^Hthe RM). :-( -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: mod_autoindex icons wrong?
On Wed, 6 Feb 2002, Justin Erenkrantz wrote: > * mod_autoindex displays the wrong icon for subdirectories on Unix > > I'd like to see it fixed in 2.0.32, but I don't know the > details. -- justin I thought that was fixed? --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
mod_autoindex icons wrong?
Anyone have any details on: * mod_autoindex displays the wrong icon for subdirectories on Unix I'd like to see it fixed in 2.0.32, but I don't know the details. -- justin
Re: Releases, showstoppers, and vetos
There has never been a formal position on what a SHOWSTOPPER is. The earliest uses were things that "either should be fixed or we decide aren't a problem anymore". That's my current understanding of it as well. The RM has "final" authority... he can say "I don't want to release until we have these fixed" and hold to them, but there is no obligation to do so. Basically, it's a way to prioritize problems. People should go over the old STATUS files... they were back then incredibly useful, but now they are bloated and confusing. Personally, restoring STATUS to what it used to be would be useful, we can move the rest of the kruft into DEVELOPER_NOTES or whatever. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: Releases, showstoppers, and vetos
* On 2002-02-06 at 16:38, Roy T. Fielding <[EMAIL PROTECTED]> excited the electrons to say: > > A showstopper is just an issue! Damnit guys, if you can't figure this out > I am going to remove the whole category from STATUS as being obviously bad > for your brain cells. Then someone else will probably put it back in.. > The only person who can declare an issue as being a showstopper is > the RM, since they are the one waiting until after the fix is made > before creating a tarball. This might need modification for a couple of reasons: the times when there isn't a pending release and hence no RM, and the general toothlessness of the RM position in general. Jim's probably been RM more than anyone else here; any thoughts, Jim? -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: 2.0.31 + fixes
Jeff Trawick wrote: > > Justin Erenkrantz <[EMAIL PROTECTED]> writes: > > > I've now posted a patch against 2.0.31 that should fix all problems > > seen so far that have been listed in STATUS. > > > > It's at: > > > > http://www.apache.org/~jerenkrantz/httpd-2.0.jre.patch > > What Greg is running now is missing this stuff from your patch: > > . canonical name change > . loglevel changes > . anonymous shmem calculation (run-time error) > . shmem ptr arithmetic (compile-time error) > > I have no strong feelings about whether or not the canonical name > change should be in a hypothetical 2.0.32 beta. I think the other > three items should definitely be in a hypothetical 2.0.32 beta. +1 on turning Justin's patch into 2.0.32 somehow. I don't care one way or another about the four things I'm missing at the moment (as long as they work, of course :) . My short term goal was to produce something post-.31 that is stable. It looks like we have achieved that goal. Once I really had the ap_rgetline patch applied, Jeff was unable to break the input side, so ignore all the recent coredumps. I was able to log in to the bug db normally. Log replay didn't hiccup. fwiw, the test server on port 8092 got scanned by a web crawler with no ill effects. I'm putting this into production when the traffic quiets down. Greg
Re: Releases, showstoppers, and vetos
> I add a showstopper to STATUS. One other person says "-1, that's > not a showstopper". By my interpretation of the rules, they CANNOT > demote it from showstopper until there are enough people who would > vote to release (more +1s than -1s). This means that in order to > demote it, there would have to be two -1s to offset my +1. A showstopper is just an issue! Damnit guys, if you can't figure this out I am going to remove the whole category from STATUS as being obviously bad for your brain cells. A problem that is a showstopper is simply AN OPINION that there won't be a majority +1 approval of a release until it is fixed. Obviously, if there is *ANY* debate on whether or not something is a showstopper, then it doesn't belong in that category -- it doesn't become a showstopper until it has the effect of stopping the show. It is just an opinion until someone calls for a vote. The only person who can declare an issue as being a showstopper is the RM, since they are the one waiting until after the fix is made before creating a tarball. Otherwise, they are free to ignore *any* issue that doesn't involve an outstanding veto on HEAD. Those are the rules that we've lived by for a long time now, and there is no way in hell that I'll support the notion that anyone can stop a release without a formal vote. Roy
Re: Releases, showstoppers, and vetos
* On 2002-02-06 at 16:15, Roy T. Fielding <[EMAIL PROTECTED]> excited the electrons to say: > > Nobody can veto a release, period. It is therefore impossible for > anything to be a showstopper unless it is a pending veto of a commit > or the group makes a decision by majority of -1 on any release until > the problem is fixed. If the RM doesn't think that is the case, > then they should move the issue out of that category. If anyone else > has a problem with that, they are perfectly capable of calling for > a vote on not releasing the code until the issue is fixed. Nor particularly streamlined, but all right. :-) > The only reason the showstopper category exists is because I needed > a place to keep track of problems that we all agreed to fixing before > I could cut a release. That is all. Now it is just being abused. Or evolving beyond your original needs and intentions. :-) 'It's a group thing.' -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: 2.0.31 + fixes
On Wed, Feb 06, 2002 at 04:01:52PM -0500, Jeff Trawick wrote: > Justin Erenkrantz <[EMAIL PROTECTED]> writes: > > > I've now posted a patch against 2.0.31 that should fix all problems > > seen so far that have been listed in STATUS. > > > > It's at: > > > > http://www.apache.org/~jerenkrantz/httpd-2.0.jre.patch > > What Greg is running now is missing this stuff from your patch: > > . canonical name change > . loglevel changes > . anonymous shmem calculation (run-time error) > . shmem ptr arithmetic (compile-time error) > > I have no strong feelings about whether or not the canonical name > change should be in a hypothetical 2.0.32 beta. I think the other > three items should definitely be in a hypothetical 2.0.32 beta. I think it should be there, and I'm RM of my own tree. =) And, it makes the diffs slightly less between core.c and HEAD. I also added Sander's recent commit to fix a overrun in the pools code. Once daedalus is running .31+ happily, I'll see about tagging JRE_1 and trying to get a tarball built off of that for possible review. -- justin
Re: Releases, showstoppers, and vetos
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]> Sent: Wednesday, February 06, 2002 3:02 PM > From: "Rodent of Unusual Size" <[EMAIL PROTECTED]> > Sent: Wednesday, February 06, 2002 2:53 PM > > > I think that's bogus, too. If someone thinks something is serious > > enough to stop a release, they should be no more overridable than > > any other block (read: veto). I find the idea of being able > > to veto a showstopper completely ludicrous. :-) > > WRONG. You are proposing that one individual may block a release. Let me add one thought. A veto is not a showstopper - it's a much higher and binding entity. However, if someone puts in the SHOWSTOPPER list "* Outstanding Veto of foo patch" then that showstopper could not be moved, by anyone, other than the veto'er (or the list if the veto was unanimously agreed to be an invalid veto.) A showstopper isn't a veto; but a veto is a showstopper. You must veto something specific to carry a showstopper over other's heads. Bill
Re: Releases, showstoppers, and vetos
On Wed, Feb 06, 2002 at 03:33:04PM -0500, Rodent of Unusual Size wrote: > "Roy T. Fielding" wrote: > > > > A showstopper, aside from a yet-to-be-reverted veto, can be > > moved from one section of STATUS to another by the RM (or > > anyone, for that matter) whenever they want. It is only > > a showstopper if we ALL agree it is. The category only exists > > to simply remind us of what needs to be fixed. > > Not codified, and certainly not clear: Yes it is codified -- the status file and its categories has no bearing whatsoever on our process guidelines except in that it keeps track of the status of voting/releases. It does not change the meaning of the votes or what is required to do a release. It is just a tool. Roy
Re: Releases, showstoppers, and vetos
Nobody can veto a release, period. It is therefore impossible for anything to be a showstopper unless it is a pending veto of a commit or the group makes a decision by majority of -1 on any release until the problem is fixed. If the RM doesn't think that is the case, then they should move the issue out of that category. If anyone else has a problem with that, they are perfectly capable of calling for a vote on not releasing the code until the issue is fixed. The only reason the showstopper category exists is because I needed a place to keep track of problems that we all agreed to fixing before I could cut a release. That is all. Now it is just being abused. Roy
Re: Releases, showstoppers, and vetos
* On 2002-02-06 at 15:59, William A. Rowe, Jr. <[EMAIL PROTECTED]> excited the electrons to say: > > WRONG. You are proposing that one individual may block a release. Yes. > That is diametrically opposed to the spirit of HTTP. Rubbish. I mean, "I disagree." > We are [now] treating showstoppers in 2.0 as sancrosect. That > means they can be overridden. If they're sacrosanct, then they can't be overridden. > But one individual cannot block the progress of the Apache HTTP > Project. Stopping a release from happening is far from 'blocking the progress of the project.' I'm saying that if one of our core developers thinks the code is so broken it shouldn't be released, then it shouldn't be released until the issue is resolved to that person's satisfaction. The problem, of course, is that a code veto can stand forever, but we cannot allow a release to be blocked that way. So I guess I'll back down some. :-) But only to the point that it needs a majority to demote a showstopper. I still don't support the idea that 'the RM or anyone' can do so arbitrarily. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: Releases, showstoppers, and vetos
At 03:53 PM 02/06/2002, Rodent of Unusual Size wrote: >Greg Marr wrote: > > > > I read that last sentence as: "An issue becomes a showstopper when > > it is listed as such in STATUS, and remains one until someone > vetoes > > it, at which time it is no longer a showstopper. ..." > >I think that's bogus, too. If someone thinks something is serious >enough to stop a release, they should be no more overridable than >any other block (read: veto). I find the idea of being able to veto >a showstopper completely ludicrous. :-) It could be. I wasn't expressing an opinion one way or another, just attempting to interpret the current guidelines. -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: Releases, showstoppers, and vetos
On Wed, Feb 06, 2002 at 03:53:09PM -0500, Rodent of Unusual Size wrote: > Greg Marr wrote: > > > > I read that last sentence as: "An issue becomes a showstopper when > > it is listed as such in STATUS, and remains one until someone vetoes > > it, at which time it is no longer a showstopper. ..." > > I think that's bogus, too. If someone thinks something is serious > enough to stop a release, they should be no more overridable than > any other block (read: veto). I find the idea of being able > to veto a showstopper completely ludicrous. :-) And I completely agree with you, Ken. But as I pointed out in my previous email, I think this is already covered by our release guidelines. If a simple majority of people would still vote +1 for a release while a particular issue was a showstopper, then by definition it should no longer be a showstopper. In all other cases, it shall remain a showstopper. Example: I add a showstopper to STATUS. One other person says "-1, that's not a showstopper". By my interpretation of the rules, they CANNOT demote it from showstopper until there are enough people who would vote to release (more +1s than -1s). This means that in order to demote it, there would have to be two -1s to offset my +1. If this is any clearer than what we have in the guidelines, I propose we include similiar verbage. -aaron
Re: Releases, showstoppers, and vetos
From: "Rodent of Unusual Size" <[EMAIL PROTECTED]> Sent: Wednesday, February 06, 2002 2:53 PM > Greg Marr wrote: > > > > I read that last sentence as: "An issue becomes a showstopper when > > it is listed as such in STATUS, and remains one until someone vetoes > > it, at which time it is no longer a showstopper. ..." > > I think that's bogus, too. If someone thinks something is serious > enough to stop a release, they should be no more overridable than > any other block (read: veto). I find the idea of being able > to veto a showstopper completely ludicrous. :-) WRONG. You are proposing that one individual may block a release. That is diametrically opposed to the spirit of HTTP. We are [now] treating showstoppers in 2.0 as sancrosect. That means they can be overridden. It does not mean they may be removed from STATUS, they may be moved from SHOWSTOPPERS to NEEDS A FIX. But one individual cannot block the progress of the Apache HTTP Project. If they can, it's time for a heated debate in pmc@, followed by board approval of a new charter for this project. Bill
Re: 2.0.31 + fixes
Justin Erenkrantz <[EMAIL PROTECTED]> writes: > I've now posted a patch against 2.0.31 that should fix all problems > seen so far that have been listed in STATUS. > > It's at: > > http://www.apache.org/~jerenkrantz/httpd-2.0.jre.patch What Greg is running now is missing this stuff from your patch: . canonical name change . loglevel changes . anonymous shmem calculation (run-time error) . shmem ptr arithmetic (compile-time error) I have no strong feelings about whether or not the canonical name change should be in a hypothetical 2.0.32 beta. I think the other three items should definitely be in a hypothetical 2.0.32 beta. I didn't compare Greg's dbm patches with those sections of your patch. As long as daedalus can open the bug db password file with 2.0.32 I'm relatively happy :) (That is the extent to which I could verify it anyway.) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Releases, showstoppers, and vetos
* On 2002-02-06 at 15:54, Justin Erenkrantz <[EMAIL PROTECTED]> excited the electrons to say: > > I think there is a higher barrier of entry to have an item listed > as a showstopper. If people can not reproduce a problem listed as > a showstopper or do not believe it is a showstopper, then they are > justified in asking for clarifications. If the person who added > it doesn't come up with a clarification, then I believe it is > permissible to remove it as a showstopper. Same deal for vetos; a veto without a valid technical justification isn't a veto. I could go along with a showstopper requiring reproducibility or at least corroboration, but still not with anyone being able to disagree for no particular reason and have it stick. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: Releases, showstoppers, and vetos
On Wed, Feb 06, 2002 at 03:37:44PM -0500, Greg Marr wrote: > FYI, from my reading, I concur that vetos apply in this situation, > but they apply to the issue being a showstopper, not to the > showstopper stopping a release. I read that last sentence as: "An > issue becomes a showstopper when it is listed as such in STATUS, and > remains one until someone vetoes it, at which time it is no longer a > showstopper. Thus, a consensus is required for an issue to be a > showstopper, and anyone can move something out of the showstopper > category at any time." +1. I think there is a higher barrier of entry to have an item listed as a showstopper. If people can not reproduce a problem listed as a showstopper or do not believe it is a showstopper, then they are justified in asking for clarifications. If the person who added it doesn't come up with a clarification, then I believe it is permissible to remove it as a showstopper. No one is removing things from STATUS. We are just demoting it from showstopper because the group agrees particular items aren't showstoppers. If one person felt so strongly about an issue that no one else wants to fix, they should fix the problem rather than complaining that the group doesn't agree it's a showstopper. -- justin
Re: Releases, showstoppers, and vetos
Greg Marr wrote: > > I read that last sentence as: "An issue becomes a showstopper when > it is listed as such in STATUS, and remains one until someone vetoes > it, at which time it is no longer a showstopper. ..." I think that's bogus, too. If someone thinks something is serious enough to stop a release, they should be no more overridable than any other block (read: veto). I find the idea of being able to veto a showstopper completely ludicrous. :-) -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: Releases, showstoppers, and vetos
On Wed, Feb 06, 2002 at 03:33:04PM -0500, Rodent of Unusual Size wrote: > "Roy T. Fielding" wrote: > > > > A showstopper, aside from a yet-to-be-reverted veto, can be > > moved from one section of STATUS to another by the RM (or > > anyone, for that matter) whenever they want. It is only > > a showstopper if we ALL agree it is. The category only exists > > to simply remind us of what needs to be fixed. > > Not codified, and certainly not clear: > > > Showstoppers > > Showstoppers are issues that require a fix be in place > > before the next public release. They are listed in the STATUS > > file in order to focus special attention on the problem. An > > issue becomes a showstopper when it is listed as such in > > STATUS and remains so by lazy consensus. > > 'Consensus' means vetos apply, as opposed to 'majority.' I think the term "consensus" as defined in our guidelines is not appropriate for showstoppers. The overriding issue here is how we make releases. In that respect, a showstopper is something that would prevent a majority approval for a release. It is difficult to manage that concept in the STATUS file, since that means that showstoppers are really the inverse of a majority approval vote. As long as there are more people in favor of making it a showstopper, it shall remain a showstopper. IMO, this logic was applied to all recent showstopper rearranging. -aaron
Re: Releases, showstoppers, and vetos
At 03:33 PM 02/06/2002, Rodent of Unusual Size wrote: >"Roy T. Fielding" wrote: > > > > A showstopper, aside from a yet-to-be-reverted veto, can be > > moved from one section of STATUS to another by the RM (or > > anyone, for that matter) whenever they want. It is only > > a showstopper if we ALL agree it is. The category only exists > > to simply remind us of what needs to be fixed. > >Not codified, and certainly not clear: > > > Showstoppers > > Showstoppers are issues that require a fix be in place > > before the next public release. They are listed in the STATUS > > file in order to focus special attention on the problem. An > > issue becomes a showstopper when it is listed as such in > > STATUS and remains so by lazy consensus. > >'Consensus' means vetos apply, as opposed to 'majority.' FYI, from my reading, I concur that vetos apply in this situation, but they apply to the issue being a showstopper, not to the showstopper stopping a release. I read that last sentence as: "An issue becomes a showstopper when it is listed as such in STATUS, and remains one until someone vetoes it, at which time it is no longer a showstopper. Thus, a consensus is required for an issue to be a showstopper, and anyone can move something out of the showstopper category at any time." -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: 2.0.31+ coredump
Justin Erenkrantz wrote: > > On Wed, Feb 06, 2002 at 03:16:09PM -0500, Greg Ames wrote: > > ...can be accessed on daedalus via > > > > cd /usr/local/apache2_0_31.v3 > > gdb bin/httpd corefiles/httpd.core.1 > > > > This happened in test when Jeff was firing requests at it and prematurely > > closing the connection. The backtrace looks like one that I should have a patch > > for: > > I'm not sure I understand you. Have you applied that patch or not? ooops, never mind, tired operator error. I didn't apply the patch to ap_rgetline last nite. I will do so ASAP, and Jeff will beat it up again. Greg
Re: cvs commit: httpd-2.0 STATUS
Cliff Woolley wrote: > > On 6 Feb 2002 [EMAIL PROTECTED] wrote: > > > +FINAL RELEASE SHOWSTOPPERS: > > + > > +* [Ken] Test suite failures: > > + o worker is also failing some of the 'cgi' subtests : > Sorry I never noticed this in the STATUS file before, but > this is exactly the same thing I was seeing on my machine > for a while. Turns out if you run the tests as root and > don't give the apache user rights to the logs directory, > apache can't create the cgi-log, which causes all those > tests to fail because they expect that log to be there. Except that I'm not running it as root.. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: Releases, showstoppers, and vetos
"Roy T. Fielding" wrote: > > A showstopper, aside from a yet-to-be-reverted veto, can be > moved from one section of STATUS to another by the RM (or > anyone, for that matter) whenever they want. It is only > a showstopper if we ALL agree it is. The category only exists > to simply remind us of what needs to be fixed. Not codified, and certainly not clear: > Showstoppers > Showstoppers are issues that require a fix be in place > before the next public release. They are listed in the STATUS > file in order to focus special attention on the problem. An > issue becomes a showstopper when it is listed as such in > STATUS and remains so by lazy consensus. 'Consensus' means vetos apply, as opposed to 'majority.' I also disgree that anyone can (or should be able to) shuffle a showstopper around. That's bogus. Let's just demote all the current showstoppers and we have a golden release. Not. This is part of why I brought this up. I disagree with the interpretation you're placing on the guidelines. And even if it's generally accepted as the correct interpretation, then I disgree with the guidelines on this issue and want it to be discussed. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: cvs commit: httpd-2.0 STATUS
From: "Cliff Woolley" <[EMAIL PROTECTED]> Sent: Wednesday, February 06, 2002 2:13 PM > On 6 Feb 2002 [EMAIL PROTECTED] wrote: > > > +FINAL RELEASE SHOWSTOPPERS: > > + > > +* [Ken] Test suite failures: > > + o worker is also failing some of the 'cgi' subtests > > + (see http://Source-Zone.Org/Apache/regression/>): > > +Justin says: "Worker should be fine and passes httpd-test here. > > + If you can provide evidence that it can be reproduced > > + outside of httpd-test, then it's a showstopper. I > > + think it's a perl or a httpd-test problem." > > +Not a showstopper: Justin > > + > > Sorry I never noticed this in the STATUS file before, but this is exactly > the same thing I was seeing on my machine for a while. Turns out if you > run the tests as root and don't give the apache user rights to the logs > directory, apache can't create the cgi-log, which causes all those tests > to fail because they expect that log to be there. Change the directory > permissions to allow the apache user to write to that directory (normally > a very bad thing, I know, but this is just for testing) and it will > work. Alternatively, we could change the test to put the scriptlog > someplace else... I suspect that forking the cgid process before we setuid, and letting the cgid engine setuid itself after it initializes should solve this bug. Either that, or the cgi-log needs to be opened in the main server config so the cgid deamon doesn't need to do so. Bill
Re: 2.0.31+ coredump
On Wed, Feb 06, 2002 at 03:16:09PM -0500, Greg Ames wrote: > ...can be accessed on daedalus via > > cd /usr/local/apache2_0_31.v3 > gdb bin/httpd corefiles/httpd.core.1 > > This happened in test when Jeff was firing requests at it and prematurely > closing the connection. The backtrace looks like one that I should have a patch > for: I'm not sure I understand you. Have you applied that patch or not? If so, we've got another problem. Based on the stack trace, I'd expect it to have been fixed by the commits last night. -- justin
2.0.31+ coredump
...can be accessed on daedalus via cd /usr/local/apache2_0_31.v3 gdb bin/httpd corefiles/httpd.core.1 This happened in test when Jeff was firing requests at it and prematurely closing the connection. The backtrace looks like one that I should have a patch for: #0 0x8126b44 in ?? () #1 0x8070cab in get_mime_headers (r=0x8126048) at protocol.c:687 #2 0x8070f9b in ap_read_request (conn=0x8124120) at protocol.c:803 #3 0x805dda9 in ap_process_http_connection (c=0x8124120) at http_core.c:300 #4 0x806d63b in ap_run_process_connection (c=0x8124120) at connection.c:84 #5 0x806d950 in ap_process_connection (c=0x8124120, csd=0x8124048) at connection.c:231 #6 0x806384c in child_main (child_num_arg=36) at prefork.c:722 #7 0x80639a6 in make_child (s=0x809a8d8, slot=36) at prefork.c:812 #8 0x8063a13 in startup_children (number_to_start=50) at prefork.c:835 #9 0x8063da4 in ap_mpm_run (_pconf=0x8099010, plog=0x80bf010, s=0x809a8d8) at prefork.c:1042 #10 0x806966e in main (argc=3, argv=0xbfbffb24) at main.c:498 #11 0x805d95d in _start () Greg
Re: cvs commit: httpd-2.0 STATUS
On 6 Feb 2002 [EMAIL PROTECTED] wrote: > +FINAL RELEASE SHOWSTOPPERS: > + > +* [Ken] Test suite failures: > + o worker is also failing some of the 'cgi' subtests > + (see http://Source-Zone.Org/Apache/regression/>): > +Justin says: "Worker should be fine and passes httpd-test here. > + If you can provide evidence that it can be reproduced > + outside of httpd-test, then it's a showstopper. I > + think it's a perl or a httpd-test problem." > +Not a showstopper: Justin > + Sorry I never noticed this in the STATUS file before, but this is exactly the same thing I was seeing on my machine for a while. Turns out if you run the tests as root and don't give the apache user rights to the logs directory, apache can't create the cgi-log, which causes all those tests to fail because they expect that log to be there. Change the directory permissions to allow the apache user to write to that directory (normally a very bad thing, I know, but this is just for testing) and it will work. Alternatively, we could change the test to put the scriptlog someplace else... --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: Releases, showstoppers, and vetos
A showstopper, aside from a yet-to-be-reverted veto, can be moved from one section of STATUS to another by the RM (or anyone, for that matter) whenever they want. It is only a showstopper if we ALL agree it is. The category only exists to simply remind us of what needs to be fixed. Roy
Re: cvs commit: httpd-2.0/server protocol.c
"Roy T. Fielding" wrote: > > syslog priorities are lame in general. heh. take it to the next level; we could use something with the flexibility of syslog.conf(5) and the broader range of modern syslog facility codes. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
RE: UseCanonicalName considered harmful
According to Ryan Bloom: > All we are saying, is if you don't specify a > port (i.e. you don't want to use a special port), use the same port that > the original request used. +1 ciao... -- Lars Eilebrecht - You might have mail. [EMAIL PROTECTED]
Re: 2.0.31 + fixes
On Wed, Feb 06, 2002 at 02:54:26PM -0500, Greg Ames wrote: > I copied all the patches I have on my newest daedalus build to > http://www.apache.org/~gregames/ . The patches ending with .31.patch should > very closely resemble committed patches. Other than that, save_input.patch is > the usual debugging patch, and enfile.patch is to allow the child to gracefully > exit without killing the parent if accept() gets ENFILE. > > I plan to reconcile these RSN. I will take a look at merging in anything you have that I don't into my tree tonight (I have some homework I need to finish, so I may not get to it for a bit). If you beat me to the reconciliation, then please post it and I'll review it. Let's try to get consistent on what additions we are making to .31+. =) > > I could tag this as JRE_1 or something, but I'd need to branch > > out server/core.c to remove 1.143. I think this is doable, but > > I'd like feedback on what we think of that, and to know what else > > we want to add. > > I'm assuming if JRE_1 looks like a keeper, we can merge the branch back into > mainline and create a public tag out of it. ++1 if so. I don't think we'd need to "merge" it back in as all we'd have to do is tag APACHE_2_0_32 to be the same as JRE_1 if the group approves it. Any fixes go back into HEAD not this dead-end branch. -- justin
Re: cvs commit: httpd-2.0/server protocol.c
> > I think you may have done the opposite of what you expected.. > > Aren't NOTICE messages *always* logged, regardless of LogLevel? > > Oh, man. That sucks. It's #defined to be priority 5 in http_log.h, > but we ignore that level. Bah. That's bogus. NOTICE should be > priority 0 if we always print it. Switching it to DEBUG. -- justin syslog priorities are lame in general. We needed something that was both not an error and always printed (for the startup/shutdown messages) and NOTICE is the only one that made sense. That leaves INFO and DEBUG for priority-based logging. Roy
Re: 2.0.31 + fixes
Justin Erenkrantz wrote: > > I've now posted a patch against 2.0.31 that should fix all problems > seen so far that have been listed in STATUS. > > It's at: > > http://www.apache.org/~jerenkrantz/httpd-2.0.jre.patch > > The changes are as follows: > > * fix an AP_DEBUG_ASSERT() call. > - modules/http/http_protocol.c r1.391 > * fix mod_auth_dbm to use apr-util: > - modules/aaa/mod_auth_dbm.c r1.42 > - modules/aaa/config.m4 r1.54 > * fix input filtering problems, add the canonical name fix, fix the > log levels of read_request_line/get_mime_headers. > - server/protocol.c r1.81 > - server/core.c r1.147 (modified to remove r1.143 changes) > * fix shmem size calculation and fixes some void* arithmetic > - srclib/apr/shmem/unix/shm.c r1.14 > * fix APR-util to correctly detect and use Berkeley DB1 on FreeBSD, > and correct expat detection: > - srclib/apr-util/build/apu-conf.m4 r1.31 > - srclib/apr-util/dbm/apr_dbm_berkeleydb.c r1.17 I copied all the patches I have on my newest daedalus build to http://www.apache.org/~gregames/ . The patches ending with .31.patch should very closely resemble committed patches. Other than that, save_input.patch is the usual debugging patch, and enfile.patch is to allow the child to gracefully exit without killing the parent if accept() gets ENFILE. I plan to reconcile these RSN. > I could tag this as JRE_1 or something, but I'd need to branch > out server/core.c to remove 1.143. I think this is doable, but > I'd like feedback on what we think of that, and to know what else > we want to add. I'm assuming if JRE_1 looks like a keeper, we can merge the branch back into mainline and create a public tag out of it. ++1 if so. Greg
Re: 2.0.31 + fixes
Justin Erenkrantz <[EMAIL PROTECTED]> writes: > I've now posted a patch against 2.0.31 that should fix all problems > seen so far that have been listed in STATUS. ... > If the group likes these fixes and deems it beta-worthy, we > can roll this as 2.0.32. +1 (concept) We need to resolve any differences between what you came up with and what Greg came up with. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Releases, showstoppers, and vetos
It has repeatedly been stated that only code changes can be vetoed; releases cannot. Unfortunately, that doesn't appear to be explicit in the project guidelines (see http://httpd.apache.org/dev/guidelines.html>). After looking at this a bit, what I think I'm finding is that a showstopper (which blocks a release) is essentially the equivalent of a veto on the release. It's a stoppage based on a technical issue. If that's an appropriate way to view it, then we need to treat showstoppers a little differently: o whomever identifies a showstopper needs to be named next to it in the STATUS file o no-one can 'demote' a showstopper except the person who raised it in the first place It seems to me that there should be two kinds of showstoppers: those that will stop a beta, and those that will stop a final release. That hasn't been clear in the past, but making the distinction means we can says, "these have to be fixed before we can beta, and *these* have to be fixed for a real, golden release." I've made that segregation in the STATUS file. Looking at STATUS, there seems to be a lot of extraneous cruft in the SHOWSTOPPERS section -- like issues being voted. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: prefork segfaults under load
Adam Sussman <[EMAIL PROTECTED]> writes: > > make distclean > > ./configure --disable-threads old-parameters > > make && make install > > > > That fixed the problem. So, is this the right solution? Should configure always > assume --disable-threads when it sees --with-mpm=prefork? I don't believe that configure should assume --disable-threads when you're using prefork. > Given that this problem does not show up with low numbers of children, I am kind > of wondering if disabling threads is just covering up some problem that should > not affect prefork. I agree that disabling threads is covering up a problem, but I suspect that the problem is in glibc and not in Apache. Some rather lame debug suggestions: 1) make sure you have the latest glibc... maybe the problem got fixed 2) make sure you aren't running out of memory 3) grab the sources for the level of glibc you have and try to get some idea of why __pthread_reset_main_thread() might segfault -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: daedalus: httpd lost its parent again
On Wed, Feb 06, 2002 at 02:27:24PM -0500, Greg Ames wrote: > Ironically, I have a quick-n-dirty patch for that on the 2.0.31+ build I was > starting to test when I noticed this. But Jeff was able to break the new build > with premature closed connections, so I decided to go with .29. I think we're > getting real close on .31+ though. Details, Jeff? -- justin
daedalus: httpd lost its parent again
...so I cleaned up the orphans and restarted 2.0.29 at Wednesday, 06-Feb-2002 11:04:07 PST. This was the same bug that Manoj noticed last week, where we don't handle ENFILE on accept() properly: [Wed Feb 06 06:46:53 2002] [error] (23)Too many open files in system: apr_accept: (client socket) [Wed Feb 06 06:46:53 2002] [error] (23)Too many open files in system: apr_accept: (client socket) [Wed Feb 06 06:46:53 2002] [error] (23)Too many open files in system: apr_accept: (client socket) [Wed Feb 06 06:46:53 2002] [error] (23)Too many open files in system: apr_accept: (client socket) [Wed Feb 06 06:46:54 2002] [alert] Child 52598 returned a Fatal error... Apache is exiting! Ironically, I have a quick-n-dirty patch for that on the 2.0.31+ build I was starting to test when I noticed this. But Jeff was able to break the new build with premature closed connections, so I decided to go with .29. I think we're getting real close on .31+ though. Greg
Re: prefork segfaults under load
On Tue, Feb 05, 2002 at 10:45:07PM -0500, Jeff Trawick wrote:
> Adam Sussman <[EMAIL PROTECTED]> writes:
>
> > I'm seeing a lot of error messages like this in my error log under load with
> > lots of children (1300 or so):
> >
> ...
> > #0 pthread_sighandler (signo=11, ctx=
> > {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, __dsh =
>0, edi = 1074716232, esi = 0, ebp = 3221222696, esp = 3221222656, ebx = 1074726616,
>edx = 1, ecx = 0, eax = 0, trapno = 13, err = 0, eip = 1074677988, cs = 35, __csh =
>0, eflags = 66070, esp_at_signal = 3221222656, ss = 43, __ssh = 0, fpstate = 0x0,
>oldmask = 2147483648, cr2 = 0})
> > at signals.c:87
> > #1
> > #2 __pthread_reset_main_thread () at internals.h:372
> > #3 0x400e40e5 in __fork () at ptfork.c:92
> > #4 0x080762e8 in make_child (s=0x80b9378, slot=1343) at prefork.c:770
> > #5 0x0807671b in perform_idle_server_maintenance (p=0x80b7578) at prefork.c:963
> > #6 0x08076a7e in ap_mpm_run (_pconf=0x80b7578, plog=0x80e9640, s=0x80b9378) at
>prefork.c:1120
> > #7 0x0807d5d2 in main (argc=1, argv=0xbb54) at main.c:501
> > #8 0x4010d177 in __libc_start_main (main=0x807cca4 , argc=1,
>ubp_av=0xbb54, init=0x805e22c <_init>,
> > fini=0x809e010 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbb4c)
>at ../sysdeps/generic/libc-start.c:129
> > (gdb)
>
> I would try adding "--disable-threads" to the configure invocation to
> see if that helps. It looks like the pthreads library is puking.
>
> make distclean
> ./configure --disable-threads old-parameters
> make && make install
>
That fixed the problem. So, is this the right solution? Should configure always
assume --disable-threads when it sees --with-mpm=prefork?
Given that this problem does not show up with low numbers of children, I am kind
of wondering if disabling threads is just covering up some problem that should
not affect prefork.
Thoughts?
-adam
Re: [PATCH] Re: bugdb userdatabase
If the list of available database formats is determined at configure-/compile-time, it behooves us to only do binbuilds on systems that have every single one for which we provide support. It would more than just suck for a user to install one of our binaries but be unable to use gdbm even though he has it -- just because *we* didn't. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: cvs commit: httpd-2.0 STATUS
On Wed, Feb 06, 2002 at 10:43:28AM -0800, Aaron Bannert wrote: > I think it's obvious we're a no-go on .31 for beta -- let's remove this > section from STATUS and move toward .32 My preference is to incorporate a minimal patchset to .31 and call that .32. (see my last post) I have no faith in the stability of the current tree (aka HEAD) right now. Although, I am trying to use HEAD where I can, but I would be *much* more comfortable just addressing the issues we've seen on daedalus in .31 rather than trying again with a HEAD-based .32. -- justin
Re: [PATCH] Re: bugdb userdatabase
Greg Ames wrote: > Justin Erenkrantz wrote: > > >>I could have sworn that I committed that. Aha! In fact, I posted >>a patch on 7 Jan for this. >> > > applied, but: > > configuring package in srclib/apr-util now > [...] > checking for ldap support...checking for gdbm.h... no > checking for db4/db.h... no > checking for db.h... yes > checking for db_create in -ldb... no > checking for db3/db.h... no > checking for db.h... (cached) yes > checking for db_create in -ldb... (cached) no > checking for db2/db.h... no > checking for db.h... (cached) yes > checking for db_open in -ldb... no > checking for db1/db.h... no > checking for db_185.h... no > checking for Berkeley DB... not found <== ??? > checking for default DBM... sdbm (default) > > from srclib/apr-util/include/apu.h: > > /* > * we always have SDBM (it's in our codebase) > */ > #define APU_HAVE_SDBM 1 > #define APU_HAVE_GDBM 0 > #define APU_HAVE_DB 0 > > This doesn't look right. > > Has anyone tested this stuff on a system with Berkely DB? I would think that > would be a logical thing to do before yanking mod_auth_db. > I testing this on win32&linux before I commited the changes to mod_auth_dbm. I testing it with DB3/4 not 1, which is what the problem seems to be. > We're going back to 2.0.29 tonight. > > Greg > >
2.0.31 + fixes
I've now posted a patch against 2.0.31 that should fix all problems seen so far that have been listed in STATUS. It's at: http://www.apache.org/~jerenkrantz/httpd-2.0.jre.patch The changes are as follows: * fix an AP_DEBUG_ASSERT() call. - modules/http/http_protocol.c r1.391 * fix mod_auth_dbm to use apr-util: - modules/aaa/mod_auth_dbm.c r1.42 - modules/aaa/config.m4 r1.54 * fix input filtering problems, add the canonical name fix, fix the log levels of read_request_line/get_mime_headers. - server/protocol.c r1.81 - server/core.c r1.147 (modified to remove r1.143 changes) * fix shmem size calculation and fixes some void* arithmetic - srclib/apr/shmem/unix/shm.c r1.14 * fix APR-util to correctly detect and use Berkeley DB1 on FreeBSD, and correct expat detection: - srclib/apr-util/build/apu-conf.m4 r1.31 - srclib/apr-util/dbm/apr_dbm_berkeleydb.c r1.17 I could tag this as JRE_1 or something, but I'd need to branch out server/core.c to remove 1.143. I think this is doable, but I'd like feedback on what we think of that, and to know what else we want to add. If the group likes these fixes and deems it beta-worthy, we can roll this as 2.0.32. Enjoy. -- justin
Re: cvs commit: httpd-2.0 STATUS
> Linux 2.2 & 2.4, HPUX >Broken on: Win32 [no error logging within service, other bugs] >for beta > -+1 : Aaron, Jim > ++1 : Aaron >+0 : Lars, Justin, trawick >-0 : OtherBill > --1 : BillS, Ian, gregames, BrianP > +-1 : BillS, Ian, gregames, BrianP, Jim I think it's obvious we're a no-go on .31 for beta -- let's remove this section from STATUS and move toward .32 -a
Re: [PATCH] Re: bugdb userdatabase
Greg Ames <[EMAIL PROTECTED]> writes: > my top priorities: ... > 3. torture test the input side code with prematurely closed connections I will claim to have done a fair amount of this (I haven't forgotten the changes you requested). A series of tests with --with-efence --enable-pool-debug was particularly fruitful and was able to instantly drive a couple of problems that I only saw intermittently before, and only on AIX. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/server core.c
Justin Erenkrantz <[EMAIL PROTECTED]> writes: > On Wed, Feb 06, 2002 at 04:16:55PM -, [EMAIL PROTECTED] wrote: > > trawick 02/02/06 08:16:55 ... > > An obvious variation of this fix would be to change APR_BRIGADE_NORMALIZE() > > to deal with empty brigades. > > You mean APR_BRIGADE_NORMALIZE assumes a non-empty brigade, > right? -- justin yessir -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Solaris8 Problem with native compiler
jean-frederic clere <[EMAIL PROTECTED]> writes: > > Back to reality, where we need to deal with this: > > > > 1) If you want to experiment with what might work around the > > problem... You could replace APR_UNSPEC in ap_mpm_pod_check() with > > AF_INET and see if that avoids the apparent WAIT_FOREVER path in the > > resolver. > > In ap_mpm_pod_open() It helps ;-)). (shrug) > > 2) Maybe Jeff needs to learn about that particular > >apr_sockaddr_info_get() call to see if it could be changed. For > >now, I dunno. Jeff hasn't been able to do that yet :) > > I have configured with --disable-threads it works. > > It seems that getaddrinfo does not like the -mt (and libthreads.so). Does anybody have the stomach to wade around the Solaris website and/or wade through the descriptions for available patches? It sounds like system breakage. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Solaris8 Problem with native compiler
Jeff Trawick wrote: > > jean-frederic clere <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I have some problems with the httpd-2.0 (from CVS). > > Whe compiled with Sun compiler it hangs at startup: > > +++ > > > $c > > (some internal library calls omitted) > > > libsocket.so.1`getaddrinfo+0x524(ff31ac0c, 93c08, 1e62, ffbefa1c, ff31a000, > > ffbef980) > > libapr.so.0`apr_sockaddr_info_get+0x14c(d7cc4, 93c08, 0, 1e62, 0, 95930) > > ap_mpm_pod_open+0xd8(95930, 8a66c, 49, 1, ff3e, ff370330) > > prefork_open_logs+0xb0(95930, bd9f8, bfa00, 975e0, bfa00, 0) > > ap_run_open_logs+0x98(95930, bd9f8, bfa00, 975e0, 0, 0) > > main+0x864(1, ffbefc9c, ffbefca4, 87800, 0, 0) > > _start+0xb8(0, 0, 0, 0, 0, 0) > > At the moment I'm not sure why that apr_sockaddr_info_get() is > there. It looks a little mysterious to me, but I haven't looked into > it. > > As for why getaddrinfo() is hanging... It shouldn't do that :) Are > there some resolver timeouts you can set on the system? There isn't a > WAIT_FOREVER flag to getaddrinfo(), so that is a Sun question :( > > Back to reality, where we need to deal with this: > > 1) If you want to experiment with what might work around the > problem... You could replace APR_UNSPEC in ap_mpm_pod_check() with > AF_INET and see if that avoids the apparent WAIT_FOREVER path in the > resolver. In ap_mpm_pod_open() It helps ;-)). > > 2) Maybe Jeff needs to learn about that particular >apr_sockaddr_info_get() call to see if it could be changed. For >now, I dunno. I have configured with --disable-threads it works. It seems that getaddrinfo does not like the -mt (and libthreads.so). With gcc (that uses -pthreads) I have the same problem. libnls.so.1 uses threads: +++$ nm /usr/lib/libnsl.so.1 | grep mutex [3514] | 0| 0|FUNC |GLOB |0|UNDEF |_mutex_held [3933] | 0| 0|FUNC |GLOB |0|UNDEF |_mutex_init [3474] | 0| 0|FUNC |GLOB |0|UNDEF |_mutex_lock [3458] | 0| 0|FUNC |GLOB |0|UNDEF |_mutex_unlock [3625] | 0| 0|FUNC |GLOB |0|UNDEF |mutex_destroy [4419] | 0| 0|FUNC |GLOB |0|UNDEF |mutex_init [3970] | 0| 0|FUNC |GLOB |0|UNDEF |mutex_lock [1747] |649784| 80|OBJT |LOCL |0|19 |mutex_table [4070] | 0| 0|FUNC |GLOB |0|UNDEF |mutex_unlock [331] |648984| 24|OBJT |LOCL |0|19 |netpp_mutex [1718] |295600| 40|FUNC |LOCL |0|9 |rmutex_init [1719] |295640| 132|FUNC |LOCL |0|9 |rmutex_lock [1720] |295772| 116|FUNC |LOCL |0|9 |rmutex_trylock [1721] |295888| 64|FUNC |LOCL |0|9 |rmutex_unlock [454] |650328| 24|OBJT |LOCL |0|19 |rpc_door_mutex [1959] |650184| 24|OBJT |LOCL |0|19 |rpcgss_calls_mutex [240] |650280| 24|OBJT |LOCL |0|19 |svc_door_mutex [227] |681576| 24|OBJT |LOCL |0|22 |svc_exit_mutex [562] |694312| 24|OBJT |LOCL |0|22 |svc_mutex [152] |681344| 24|OBJT |LOCL |0|22 |svc_thr_mutex +++ > > --/-- > > For better or worse, some months back APR decoupled the choice of > using getaddrinfo() from the choice of enabling IPv6 support, so > --disable-ipv6 doesn't switch us to the older, better-understood > resolver logic. > > -- > Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: >http://www.geocities.com/SiliconValley/Park/9289/ > Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/server core.c
On Wed, 6 Feb 2002, Justin Erenkrantz wrote: > You mean APR_BRIGADE_NORMALIZE assumes a non-empty brigade, > right? -- justin Yeah... must have been a typo. Boy do I hate normalize... makes me need another cup of coffee just thinking about it. :) Normalize is definitely next on my hitlist. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/server core.c
On Wed, Feb 06, 2002 at 04:16:55PM -, [EMAIL PROTECTED] wrote: > trawick 02/02/06 08:16:55 > > Modified:server core.c > Log: > yet another tweak to empty brigade checking on entry to core_input_filter(): > > since APR_BRIGADE_EMPTY() assumes a non-empty brigade, we have to check > before invoking that macro > > since APR_BRIGADE_EMPTY() can make a brigade empty, we have to check > after invoking that macro > > An obvious variation of this fix would be to change APR_BRIGADE_NORMALIZE() > to deal with empty brigades. You mean APR_BRIGADE_NORMALIZE assumes a non-empty brigade, right? -- justin
Re: cvs commit: httpd-2.0/server protocol.c
On Wed, Feb 06, 2002 at 07:04:12AM -0500, Rodent of Unusual Size wrote: > [EMAIL PROTECTED] wrote: > > > > Tone down the logging levels for these two messages from > > ERROR to NOTICE. It's something to note, but it isn't an > > error worthy of logging by default. > > I think you may have done the opposite of what you expected.. > Aren't NOTICE messages *always* logged, regardless of LogLevel? Oh, man. That sucks. It's #defined to be priority 5 in http_log.h, but we ignore that level. Bah. That's bogus. NOTICE should be priority 0 if we always print it. Switching it to DEBUG. -- justin
Re: UseCanonicalName considered harmful
On Wed, Feb 06, 2002 at 11:15:36AM -0500, Rodent of Unusual Size wrote: > Ryan Bloom wrote: > > > > > ServerName MyServer.Com > > > Listen 1 > > > Listen 2 > > > Canonical name should be: MyServer.Com: > > > > I agree with all of them up through this last one. It's not that I > > disagree with this, just that I'd be perfectly happy if the Canonical > > name used 1 or 2 regardless of which port the request came in > > on. > > But if both are equally acceptable, I think we definitely need > to err on the side of using the port the original request did. > Consider the case of that port being explicitly punched through > a firewall; by redirecting to a different port even though the > original was valid, we may end up replying with a redirect the > client can't reach. It works both ways though (what if the external port maps to a different internal port), and in the end I think second guessing the admin will get us into trouble. Perhaps we should require the ServerName to have a port when there are multiple Listen statements? -aaron p.s. I've encountered this exact misconfiguration before, and of course it is made worse by the fact that it seems like it is working at first, until someone hits a directory url without the trailing slash...*sigh*
RE: UseCanonicalName considered harmful
> > > ServerName MyServer.Com > > > Listen 1 > > > Listen 2 > > > Canonical name should be: MyServer.Com: > > > > I agree with all of them up through this last one. It's not that I > > disagree with this, just that I'd be perfectly happy if the Canonical > > name used 1 or 2 regardless of which port the request came in > > on. > > But if both are equally acceptable, I think we definitely need > to err on the side of using the port the original request did. > Consider the case of that port being explicitly punched through > a firewall; by redirecting to a different port even though the > original was valid, we may end up replying with a redirect the > client can't reach. You convinced me. I should have the patch soon. I was reading this code last night, and it looks like a one or two-liner. :-) Ryan
Re: UseCanonicalName considered harmful
Ryan Bloom wrote: > > > ServerName MyServer.Com > > Listen 1 > > Listen 2 > > Canonical name should be: MyServer.Com: > > I agree with all of them up through this last one. It's not that I > disagree with this, just that I'd be perfectly happy if the Canonical > name used 1 or 2 regardless of which port the request came in > on. But if both are equally acceptable, I think we definitely need to err on the side of using the port the original request did. Consider the case of that port being explicitly punched through a firewall; by redirecting to a different port even though the original was valid, we may end up replying with a redirect the client can't reach. > Unless you want to code this, I can have something committed today. Go for it. You're a lot more familiar with that code than am I. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: UseCanonicalName considered harmful
On Wed, Feb 06, 2002 at 07:59:50AM -0800, Ryan Bloom wrote: > why don't you think that is possible with these changes? Right now, if > you don't specify a port in the ServerName directive, we use the default > port for the protocol. All we are saying, is if you don't specify a > port (i.e. you don't want to use a special port), use the same port that > the original request used. D'oh -- I totally skipped the use cases that make this obvious. That's what I get for posting so early in the morning. In that case, and as long as I can specify the exact hostname:port, then I am +1. -aaron
Add errors to short_record
Suggestion for 1.3: add "unsigned short error_count" to short_record in scoreboard.h Number would be incremented by each child using ap_is_HTTP_ERROR(r->status) at log phase. Should only be enable when ExtendedStatus On Would make statistics gathering much easier. -- Brian Akins Systems Engineer III CNN Internet Technologies
RE: UseCanonicalName considered harmful
> On Wed, Feb 06, 2002 at 09:44:22AM -0500, Rodent of Unusual Size wrote: > > ServerName MyServer.Com > > Listen 1 > > Listen 2 > > Canonical name should be: MyServer.Com: > > It's this case that makes me think we should just rename ServerName to > something like CanonicalServerName and require that it always be of the > form "servername:port". > > It is useful for Apache to report itself running on a different port > than it's listening, but I don't see how we can do that with the > proposed changes. The typical use case for this is an apache server why don't you think that is possible with these changes? Right now, if you don't specify a port in the ServerName directive, we use the default port for the protocol. All we are saying, is if you don't specify a port (i.e. you don't want to use a special port), use the same port that the original request used. Ryan
Re: UseCanonicalName considered harmful
On Wed, Feb 06, 2002 at 09:44:22AM -0500, Rodent of Unusual Size wrote: > ServerName MyServer.Com > Listen 1 > Listen 2 > Canonical name should be: MyServer.Com: It's this case that makes me think we should just rename ServerName to something like CanonicalServerName and require that it always be of the form "servername:port". It is useful for Apache to report itself running on a different port than it's listening, but I don't see how we can do that with the proposed changes. The typical use case for this is an apache server behind a NAT firewall that redirects an external IP:port to an internal IP:port. -- Same case is for some load balancers. -aaron
Re: UseCanonicalName considered harmful
On Wed, Feb 06, 2002 at 07:45:44AM -0800, Ryan Bloom wrote: > > The Port directive was removed from 2.0, because it confuses too many > people. Good :-) Tony.
Re: UseCanonicalName considered harmful
We're talking 2.0, so Port isn't available anyway. Rodent of Unusual Size wrote: > > Tony Finch wrote: > > > > Yes, with the addition that any Port directive is used to create the > > canonical name in preference to the port from the Listen directive, i.e. > > > > ServerName dotat.at > > Port 8000 > > > > is the same as > > > > ServerName dotat.at:8000 > > No, that just promulgates the current brokenness. If there > was also a Listen 1 (I assume you omitted an example > Listen by accident), your method would result in a dotat.at:8000 > even if the request came in on 1. I feel that if there > is *any* ambiguity, the canonicalisation should use the same > port that the original request used. > -- > #ken P-)} > > Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ > Author, developer, opinionist http://Apache-Server.Com/ > > "Millennium hand and shrimp!" > -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
RE: UseCanonicalName considered harmful
> ServerName MyServer.Com > Listen 1 > Listen 2 > Canonical name should be: MyServer.Com: I agree with all of them up through this last one. It's not that I disagree with this, just that I'd be perfectly happy if the Canonical name used 1 or 2 regardless of which port the request came in on. Unless you want to code this, I can have something committed today. Ryan
RE: UseCanonicalName considered harmful
> On Wed, Feb 06, 2002 at 09:44:22AM -0500, Rodent of Unusual Size wrote: > > > > Let's see, then. Here are some test cases: > > [...] > > Does that seem about right? > > Yes, with the addition that any Port directive is used to create the > canonical name in preference to the port from the Listen directive, i.e. > > ServerName dotat.at > Port 8000 > > is the same as > > ServerName dotat.at:8000 The Port directive was removed from 2.0, because it confuses too many people. Ryan
Re: UseCanonicalName considered harmful
Tony Finch wrote: > > Yes, with the addition that any Port directive is used to create the > canonical name in preference to the port from the Listen directive, i.e. > > ServerName dotat.at > Port 8000 > > is the same as > > ServerName dotat.at:8000 No, that just promulgates the current brokenness. If there was also a Listen 1 (I assume you omitted an example Listen by accident), your method would result in a dotat.at:8000 even if the request came in on 1. I feel that if there is *any* ambiguity, the canonicalisation should use the same port that the original request used. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: [PATCH] Re: bugdb userdatabase
Justin Erenkrantz wrote: > > On Tue, Feb 05, 2002 at 11:10:41PM -0500, Greg Ames wrote: > > Has anyone tested this stuff on a system with Berkely DB? I would think that > > would be a logical thing to do before yanking mod_auth_db. > > FreeBSD's variant wasn't detected (I have to use BDB 4.0.14 for SVN, > so I never use anything else). Thanks! I think you're saying that you tested some variant of Berkely DB, so I feel much better about this change. > If you are interested, you can use testdbm in apr-util/test like so: > > testdbm -t DB cat /home/apmail/bugdbaccounts I'm definately interested. > to ensure that apr-util can read it correctly. And, if apr-util > can read it, mod_auth_dbm better be able to. =) I tested with > testdbm on daedalus, so we should be fine there. beautyous :) :) > What would be a timeframe to try to go back to .31 with this > fix in? my top priorities: 1. insure the bug db stuff works post-.31 2. check out the new flavor of core dump Jeff moved into /usr/local/apache2_0_31.patched/corefiles 3. torture test the input side code with prematurely closed connections 4. get .31 + new patches running live on daedalus 5. think about how we can re-tag a stable set of code similar to that in step 4 > As you can tell, we need the feedback, *but* we are > getting a rather quick turnaround on any problems. =) yep...I definately appreciate your efforts, and hope you got enough sleep last nite and/or coffee today :) Greg
Re: UseCanonicalName considered harmful
On Wed, Feb 06, 2002 at 09:44:22AM -0500, Rodent of Unusual Size wrote: > > Let's see, then. Here are some test cases: > [...] > Does that seem about right? Yes, with the addition that any Port directive is used to create the canonical name in preference to the port from the Listen directive, i.e. ServerName dotat.at Port 8000 is the same as ServerName dotat.at:8000 Tony.
Re: UseCanonicalName considered harmful
Rodent of Unusual Size wrote: > > Does that seem about right? > +1 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
RE: HTTP, Internet Explorer, and *large* POSTs
Jerry, I've been trying to nail this one for a while now but have not been able to recreate - do you have a testcase that will generate the questionable POST request? What is catching the POST on the server - a CGI? What platform is the server? Please send any further info to me directly rather than through the list. Thanks, Allan > Large POSTs, say of 8K bytes fail. When I've examined this with tcpdump, > I've seen that Internet Explorer has not sent out one POST but will > sometimes send out two or even three POSTs of the same URL. Only the first > POST that is sent out will contain the POST data. And even better, > sometimes the third POST transforms itself into a GET. It seems to be a > function of the length of the POST, but that length is not repeatable. It > happens much more often with long POSTs, say of 8K, but on occasion, I > believe I've seen it happen with as few as a 1K byte POST.
RE: UseCanonicalName considered harmful
> From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]] > Does that seem about right? Or in other words (just to make sure I understand), the ServerName directive will no longer default to using port 80 if no port is specified. Instead, it will default to using the actual port on which the request is received. That makes sense to me. Joshua.
Re: UseCanonicalName considered harmful
* On 2002-02-06 at 06:18, Roy T. Fielding <[EMAIL PROTECTED]> excited the electrons to say: > > I'm with Ryan (and we've had this discussion before). The code is > busted. Just fix it -- no need for a config change. Works for me.. Let's see, then. Here are some test cases: ServerName MyServer.Com [No Listen statement] Canonical name should be: MyServer.Com ServerName MyServer.Com Listen 80 Canonical name should be: MyServer.Com ServerName MyServer.Com Listen 1 Canonical name should be: MyServer.Com:1 ServerName MyServer.Com:1 [No Listen statement] Canonical name should be: MyServer.Com:1 ServerName MyServer.Com:1 Listen 80 Canonical name should be: MyServer.Com:1 ServerName MyServer.Com:1 Listen 2 Canonical name should be: MyServer.Com:1 ServerName MyServer.Com Listen 1 Listen 2 Canonical name should be: MyServer.Com: Does that seem about right? -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: cvs commit: httpd-2.0/server protocol.c
[EMAIL PROTECTED] wrote: > > Tone down the logging levels for these two messages from > ERROR to NOTICE. It's something to note, but it isn't an > error worthy of logging by default. I think you may have done the opposite of what you expected.. Aren't NOTICE messages *always* logged, regardless of LogLevel? -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: [PATCH] Re: bugdb userdatabase
On Tue, Feb 05, 2002 at 11:10:41PM -0500, Greg Ames wrote: > Has anyone tested this stuff on a system with Berkely DB? I would think that > would be a logical thing to do before yanking mod_auth_db. FreeBSD's variant wasn't detected (I have to use BDB 4.0.14 for SVN, so I never use anything else). I just added autoconf magic to detect it. Please see the STATUS file in httpd-2.0 for revision numbers to retrieve for proper operation with DB1 files. I also found a bug in how we did the DB1 iteration and fixed that. If you are interested, you can use testdbm in apr-util/test like so: testdbm -t DB cat /home/apmail/bugdbaccounts to ensure that apr-util can read it correctly. And, if apr-util can read it, mod_auth_dbm better be able to. =) I tested with testdbm on daedalus, so we should be fine there. What would be a timeframe to try to go back to .31 with this fix in? As you can tell, we need the feedback, *but* we are getting a rather quick turnaround on any problems. =) -- justin
Re: Current HEAD on Win32
"William A. Rowe, Jr." wrote: >> (This posting maybe a dupe, I hope it's not) > Nope. Okay, if this mail goes through, then the Apache.org listserver checks whether a email address is subscribed not only using the From: header, but using !MAIL FROM: and / or Return-Path:. > It's crufty and taking a while, might be a few hours before all is > very well again. No problem, Sebastian -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
