Bug report for Apache httpd-1.3 [2004/05/16]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 7741|New|Nor|2002-04-04|some directives may be placed outside of proper co| | 7982|New|Maj|2002-04-11|mod_rewrite URL string empty when passed unicoded | | 8311|Opn|Nor|2002-04-19|error in PUT directive gives confusing error messa| | 8329|New|Nor|2002-04-20|mime_magic gives 500 and no error_log on Microsoft| | 8372|Ass|Nor|2002-04-22|Threadsaftey issue in Rewrite's cache [Win32/OS2/N| | 8849|New|Nor|2002-05-07|make install errors as root on NFS shares | | 8882|New|Enh|2002-05-07|[PATCH] mod_rewrite communicates with external rew| | 9037|New|Min|2002-05-13|Slow performance when acessing an unresolved IP ad| | 9126|New|Blk|2002-05-15|68k-next-openstep v. 4.0 | | 9726|New|Min|2002-06-09|Double quotes should be flagged as T_HTTP_TOKEN_ST| | 9894|New|Maj|2002-06-16|getline sub in support progs collides with existin| | |New|Nor|2002-06-19|Incorrect default manualdir value with layout.| |10038|New|Min|2002-06-20|ab benchmaker hangs on 10K https URLs with keepali| |10073|New|Maj|2002-06-20|upgrade from 1.3.24 to 1.3.26 breaks include direc| |10169|New|Nor|2002-06-24|Apache seg faults due to attempt to access out of | |10178|New|Maj|2002-06-24|Proxy server cuts off begining of buffer when spec| |10195|New|Nor|2002-06-24|Configure script erroneously detects system Expat | |10199|New|Nor|2002-06-24|Configure can't handle directory names with unders| |10243|New|Maj|2002-06-26|CGI scripts not getting POST data | |10354|New|Nor|2002-06-30|ErrorDocument(.htaccess) fails when passed URL wit| |10470|New|Cri|2002-07-04|proxy module will not correctly serve mixed case f| |10666|New|Enh|2002-07-10|line-end comment error message missing file name | |10744|New|Nor|2002-07-12|suexec might fail to open log file| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |10760|New|Maj|2002-07-12|empty ftp directory listings from cached ftp direc| |10890|New|Cri|2002-07-17|if et locale is used, configure fails | |10939|New|Maj|2002-07-18|directory listing errors | |11020|New|Maj|2002-07-21|APXS only recognise tests made by ./configure | |11236|New|Min|2002-07-27|Possible Log exhaustion bug? | |11265|New|Blk|2002-07-29|mod_rewrite fails to encode special characters| |11765|New|Nor|2002-08-16|.apaci.install.tmp installs in existing httpd.conf| |11986|New|Nor|2002-08-23|Restart hangs when piping logs on rotation log pro| |11993|Opn|Cri|2002-08-23|PDFs served through ProxyPass show up blank | |12096|New|Nor|2002-08-27|apxs does not handle binary dists installed at non| |12391|New|Maj|2002-09-07|DBM_LIB should be blank for OS X 10.2 | |12551|New|Nor|2002-09-11|mod_proxy fails to shutdown when client cancels | |12574|New|Nor|2002-09-12|Broken images comes from mod_proxy when caching ww| |12583|New|Nor|2002-09-12|First piped log process do not handle SIGTERM | |12598|New|Maj|2002-09-12|Apache hanging in Keepalive State | |13120|New|Cri|2002-09-29|CGI procs defunctioning | |13188|New|Nor|2002-10-02|does not configure correctly for hppa64-hp-hpux11.| |13274|Ass|Nor|2002-10-04|Subsequent requests are destroyed by the request e| |13577|New|Nor|2002-10-13|mod_proxy mangles query string| |13607|Opn|Enh|2002-10-14|Catch-all enhancement for vhost_alias?| |13687|New|Min|2002-10-16|Leave Debug symbol on Darwin | |13822|New|Maj|2002-10-21|Problem while running Perl modules accessing CGI::| |14031|New|Nor|2002-10-29|POST handling for multi part forms incorrect | |14095|Opn|Nor|2002-10-30|Change default Content-Type (DefaultType) in defau| |14250|New|Maj|2002-11-05|Alternate UserDirs don't work intermittantly | |14358|New|Enh|2002-11-07|rotatelogs using TZ settings | |14443|New|Maj|2002-11-11|Keep-Alive randomly causes TCP RSTs |
Bug report for Apache httpd-2.0 [2004/05/16]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 7483|Ass|Enh|2002-03-26|Add FileAction directive to assign a cgi interpret| | 7862|New|Enh|2002-04-09|suexec never log a group name.| | 8167|New|Min|2002-04-16|--with-module does not build MODULE_DIRS correctly| | 8483|Opn|Min|2002-04-24|apache_2.0 .msi installer breaks .log and .conf fi| | 8500|Ass|Cri|2002-04-25|authorization user does not logged| | 8713|New|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity| | 8867|Opn|Cri|2002-05-07|exports.c generation fails when using a symlink to| | 8880|New|Enh|2002-05-07|AcceptPathInfo does not apply to DirectoryIndex fi| | 8925|New|Cri|2002-05-09|Service Install (win32 .msi/.exe) fails for port i| | 8993|Opn|Nor|2002-05-10|openssl library location(s) are hardcoded in confi| | 9046|New|Min|2002-05-13|Cleaned up PNG/MNG converted icons| | 9484|New|Enh|2002-05-29|Dynamic ServerAdmin configuration | | 9513|Opn|Nor|2002-05-30|Missing start menu items | | 9656|New|Nor|2002-06-06|Support of FTP Proxy only partially documented| | 9727|New|Min|2002-06-09|Double quotes should be flagged as T_HTTP_TOKEN_ST| | 9945|New|Enh|2002-06-18|[PATCH] new funtionality for apache bench | |10114|Ass|Enh|2002-06-21|Negotiation gives no weight to order, only q value| |10154|Ass|Nor|2002-06-23|ApacheMonitor interferes with service uninstall/re| |10575|New|Enh|2002-07-09|no option to autoindex auth protected files/folder| |10598|Opn|Nor|2002-07-09|Apache will break down files bigger than 64KB | |10722|New|Nor|2002-07-12|ProxyPassReverse doesn't change cookie paths | |10775|Ass|Cri|2002-07-13|SCRIPT_NAME wrong value | |11000|New|Enh|2002-07-20|Mutex permission problems: configuration template | |11035|New|Min|2002-07-22|Apache adds double entries to headers generated by| |11259|New|Enh|2002-07-29|'make install' should provide a deinstaller | |11294|New|Enh|2002-07-30|desired vhost_alias option| |11331|New|Cri|2002-07-31|stale cgi process entries when using suexec | |11427|Opn|Maj|2002-08-02|Possible Memory Leak in CGI script invocation | |11514|New|Maj|2002-08-07|worker MPM stalls on UnixWare 7.11| |11521|New|Nor|2002-08-07|Addition of Japanese error message | |11540|New|Nor|2002-08-07|ProxyTimeout ignored | |11580|Opn|Enh|2002-08-09|generate Content-Location headers | |11660|New|Enh|2002-08-13|a New Hebrew Translation for Test Page for Apache| |11960|New|Maj|2002-08-23|Apache default config doesn't include uk langauge | |12033|Opn|Nor|2002-08-26|Graceful restart immidiately result in [warn] long| |12187|Opn|Blk|2002-08-30|Standard config with perchild; Apache is blocked | |12340|Opn|Nor|2002-09-05|WindowsXP proxy, child process exited with status | |12355|Opn|Nor|2002-09-06|SSLVerifyClient directive in location make post to| |12426|Ass|Nor|2002-09-09|mod_proxy broken under high load ?| |12625|New|Enh|2002-09-13|[PATCH] Restoration of mod_ssl compatibility env v| |12680|New|Enh|2002-09-16|Digest authentication with integrity protection | |12885|New|Enh|2002-09-20|windows 2000 build information: mod_ssl, bison, et| |12894|New|Nor|2002-09-21|not assuming the DEFAULTTYPE for PHP files without| |12981|New|Nor|2002-09-25|Apache Bench can't take binary post data | |13029|New|Nor|2002-09-26|failure to generate StdEnvVars depending on charse| |13101|New|Cri|2002-09-27|Using mod_ext_filter with mod_proxy and http/1.1 c| |13272|Opn|Nor|2002-10-04|Documentation doesn't mention that SSL is not in b| |13328|New|Nor|2002-10-05|Apache kills processgroup.| |13343|New|Maj|2002-10-06|Apache2 dies if signal HUP is sent to master proce| |13368|New|Maj|2002-10-07|IIS prevents Apache from starting (missing -w opti| |13507|New|Enh|2002-10-10|capturing stderr from mod_cgi |
Broken server/exports.c generated when --with-apr=/usr
Apache is failing to build for me, because of a flaw in the exports.c generation. I am using an APR and APR-Util pre-installed into /usr. This causes the generated exports.c to included every *.h file in /usr/include. Since some of these are C++ only, and others have conflicting definitions, this breaks. I think the solution is to modify server/Makefile.in to only pass ap[ru].h and ap[ru]_*.h from $(APR_INCLUDEDIR) and $(APU_INCLUDEDIR) to exports generation. Since the other $(EXPORT_DIRS) are all within the source tree, the existing pattern of *.h is ok for them. Does this seem like the correct solution? Apache version: 2.0.49 OS: Cygwin (on Windows XP) Max.
Re: Discover which MPM is loaded?
I'm writing a module which plays with seteuid/setegid, and should therefore only be run under the prefork MPM. at low level your reliance is on a single-threaded process handling requests? That's correct - I'm switching UID/GID on every request based on the provided authenticated username. It seems to me a multi-threaded server wouldn't be able to handle this situation very well. ap_mpm_query() can check for such MPM characteristics Thanks! I'll check out that function. -- Adam Tilghman | Systems Support / Academic Computing | +1 858 822 0711 [EMAIL PROTECTED] | University of California, San Diego | fax +1 858 534 7018
Vc++ Toolkit
quote The VC toolkit does support /MT (it does not support /MD). Ronald Laeremans Visual C++ team /quote Jeff
Re: [mp2 patch] getting APR to work w/o modperl
On Sat, 15 May 2004, Stas Bekman wrote: Randy Kobes wrote: On Mon, 10 May 2004, Stas Bekman wrote: How about a quick workaround as follows: For windows only, link APR.so statically with all APR/Foo.o and the required modperl_foo.o and arrange for the bootstrap not to call it for windows if APR.so is loaded? That sounds good ... So can you try to tackle that? I guess my latest patch won't apply against the current cvs and I'll need to re-sync it and resolve collisions. I'll give it a go ... So as I'll be current, could you re-sync it, if it's not too difficult? Alternatively, if the patch is OK on others (apart from Win32, and perhaps aix), is it ready to apply, and we'll work from there? I guess all you need to do is to change xs/APR/APR/Makefile.PL to collect all .o files from under xs/APR and a few selected src/modules/perl/modperl_xxx.o and link them statically with APR.so if under win32. (and may be some other platforms too (aix comes to mind)). Just so I understand correctly, in this approach we'll have one (big) APR.so that has collected all the functionality of the individual APR::* modules (as well as the old APR.so itself and selected symbols from modperl_xxx.o)? Or does APR stay essentially the same (with the added symbols from selected modperl_xxx.o), and then one links each APR::* with APR.so? It should be relatively straightforward to do the latter (as long as APR.so is built before APR::*). However, with the former, there'd be problems building the individual APR::* modules first, to be used as components in building APR.so, for the same reason that exists now - to build APR::*, one has to specify the library where the symbols are found, and one can't specify a library (APR.so) that hasn't been built yet. This could be resolved in some cases by linking APR::* against the relevant modperl_xxx.o files; however, for those that require some functionality within APR.so itself, there might be a problem ... The only alternative I was able to come up with is to use LoadLibrary/GetProcAddress to set a function pointer to that of a function within a dll. I tried to cut this down to the minimal needed, and came up with something along the lines of, generically, typdef ... /* delare the function pointers */ HINSTANCE hlib; if (GetProcAddresses(hlib, Some.dll, fn_1, func_1, fn_2, func_2, ...) { /* the functions are available */ } if (hlib != NULL) FreeLibrary(hlib); where GetProcAddresses() is a simple (generic) routine that associates, from Some.dll, func_1, func_2, ... with fn_1, fn_2, ... So, in this approach, for each APR::* as appropriate, necessary function pointers must be declared, GetProcAddresses() is invoked, and finally, if necessary, FreeLibrary() called at the end. However, I don't have enough experience with the build system to compare if the above would be easier or harder to set up and maintain, compared to linking against the appropriate .so files. The biggest problem I see here, is that we won't be able to test whether things still work on windows, every time we change or add something. So I'd prefer not to use it. If this can be done automatically, without touching the existing code, then i guess it's OK. But I'm not quite sure this is possible. That's certainly a concern ... If this is ever attempted, I think some (most?) of it could be done somewhat automatically, but maybe it'd be better to explore the above approach first. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Move apache-1.3 to Subversion
On Fri, 2004-05-14 at 18:47, Justin Erenkrantz wrote: --On Wednesday, May 12, 2004 8:54 PM +0200 André Malo [EMAIL PROTECTED] wrote: * Jim Jagielski [EMAIL PROTECTED] wrote: I'd like to propose that the apache-1.3 tree be migrated over to subversion. I'm +1 on it. +1. -- justin +1! There's only one thing for us to decide; how to define the layout under httpd/ in the SVN repository. e.g. .../ httpd/ trunk/ branches/ 1.3.x/ 2.0.x/ tags/ 2.0.49/ ... 1.3.31/ ... Thoughts? Sander
Re: [mp2 patch] getting APR to work w/o modperl
On Sun, 16 May 2004, Randy Kobes wrote: On Sat, 15 May 2004, Stas Bekman wrote: Randy Kobes wrote: On Mon, 10 May 2004, Stas Bekman wrote: How about a quick workaround as follows: For windows only, link APR.so statically with all APR/Foo.o and the required modperl_foo.o and arrange for the bootstrap not to call it for windows if APR.so is loaded? That sounds good ... So can you try to tackle that? I guess my latest patch won't apply against the current cvs and I'll need to re-sync it and resolve collisions. I'll give it a go ... So as I'll be current, could you re-sync it, if it's not too difficult? Alternatively, if the patch is OK on others (apart from Win32, and perhaps aix), is it ready to apply, and we'll work from there? Well, I don't want to destabilize the tree, we should make a new release pretty soon. I think while you are playing with various solutions you could just check the cvs tree for the day I've posted my second patch and it should apply just fine. Your work is going to be in the xs/APR/APR area, not really touching anything else. If you think it's a problem I'll then try to post an up-to-date patch, but it may quickly become out-of-date in a few days. I guess all you need to do is to change xs/APR/APR/Makefile.PL to collect all .o files from under xs/APR and a few selected src/modules/perl/modperl_xxx.o and link them statically with APR.so if under win32. (and may be some other platforms too (aix comes to mind)). Just so I understand correctly, in this approach we'll have one (big) APR.so that has collected all the functionality of the individual APR::* modules (as well as the old APR.so itself and selected symbols from modperl_xxx.o)? Or does APR stay essentially the same (with the added symbols from selected modperl_xxx.o), and then one links each APR::* with APR.so? I was talking about the former, where APR.so will include all objects in Wrap/APR/*/.o (not .so) and some of src/modules/perl/modperl_xxx.o. I'm not sure how can you go with the latter idea. I mean, I'll work perfectly fine without mod_perl. But how is it going to work under mod_perl, when both mod_perl.so and APR.so will have the same symbols, and according to your suggestion, both will be loaded (since APR/Foo.so will be linked against APR.so). It would have worked perfectly if we could also link mod_perl.so against APR.so and not include those symbols in mod_perl.so. Which is probably the best solution possible. The problem is that the loaded will somehow have to find APR.so when trying to load mod_perl.so. This could have been done by installing APR.so along with libapr.so I suppose. In that case we will have APR a totally autonomous systems and mod_perl will use it. May be it makes perfect sense, but I haven't thought of the implications for users. It should be relatively straightforward to do the latter (as long as APR.so is built before APR::*). However, with the former, there'd be problems building the individual APR::* modules first, to be used as components in building APR.so, for the same reason that exists now - to build APR::*, one has to specify the library where the symbols are found, and one can't specify a library (APR.so) that hasn't been built yet. But I was talking about building .o objects, not shared libs. and linking those .o objects with APR.so. Will that be a problem too? AFAIK you never need to provide information about shared libs, during compilation time. Is that different on windows? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 patch] getting APR to work w/o modperl
On Sun, 16 May 2004, Stas Bekman wrote: On Sun, 16 May 2004, Randy Kobes wrote: [ .. ] Well, I don't want to destabilize the tree, we should make a new release pretty soon. I think while you are playing with various solutions you could just check the cvs tree for the day I've posted my second patch and it should apply just fine. Your work is going to be in the xs/APR/APR area, not really touching anything else. If you think it's a problem I'll then try to post an up-to-date patch, but it may quickly become out-of-date in a few days. Sounds good ... I guess all you need to do is to change xs/APR/APR/Makefile.PL to collect all .o files from under xs/APR and a few selected src/modules/perl/modperl_xxx.o and link them statically with APR.so if under win32. (and may be some other platforms too (aix comes to mind)). Just so I understand correctly, in this approach we'll have one (big) APR.so that has collected all the functionality of the individual APR::* modules (as well as the old APR.so itself and selected symbols from modperl_xxx.o)? Or does APR stay essentially the same (with the added symbols from selected modperl_xxx.o), and then one links each APR::* with APR.so? I was talking about the former, where APR.so will include all objects in Wrap/APR/*/.o (not .so) and some of src/modules/perl/modperl_xxx.o. OK, that makes sense ... I'm not sure how can you go with the latter idea. I mean, I'll work perfectly fine without mod_perl. But how is it going to work under mod_perl, when both mod_perl.so and APR.so will have the same symbols, and according to your suggestion, both will be loaded (since APR/Foo.so will be linked against APR.so). In this approach I don't there's a problem on Windows with linking against libraries with the same symbols; depending on the order of the libraries in the link command, VC++ will resolve the symbols not found in the object files in the 1st library file it finds that has them (which then registers the corresponding .so, if it's a shared library), so any identical symbols in a later library used in the link command are ignored. Thus, you could in principle build an application linked against two dlls that have the same symbols in them and there shouldn't be a conflict, as the application knows, from how it was linked, which dll each symbol comes from. However, this also means that no symbols can be resolved through mod_perl.lib, as this would require loading mod_perl.so (unless one used the -delayload link option, to load the dll only if a symbol is invoked). It would have worked perfectly if we could also link mod_perl.so against APR.so and not include those symbols in mod_perl.so. Which is probably the best solution possible. The problem is that the loaded will somehow have to find APR.so when trying to load mod_perl.so. This could have been done by installing APR.so along with libapr.so I suppose. In that case we will have APR a totally autonomous systems and mod_perl will use it. May be it makes perfect sense, but I haven't thought of the implications for users. It should be relatively straightforward to do the latter (as long as APR.so is built before APR::*). However, with the former, there'd be problems building the individual APR::* modules first, to be used as components in building APR.so, for the same reason that exists now - to build APR::*, one has to specify the library where the symbols are found, and one can't specify a library (APR.so) that hasn't been built yet. But I was talking about building .o objects, not shared libs. and linking those .o objects with APR.so. Will that be a problem too? AFAIK you never need to provide information about shared libs, during compilation time. Is that different on windows? No, you're right - resolving all symbols only is required at link time, so this could be done by just compiling (with -c) the APR::* files to build the object files, and skip building the associated APR::* dlls, as is done now. I think things are becoming clearer to me - thanks. It looks like most of this can be done by fiddling with the compiling/linking commands, without the need (hopefully) of any source code modifications. I'll try it and see. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 patch] getting APR to work w/o modperl
Randy Kobes wrote: [...] I'm not sure how can you go with the latter idea. I mean, I'll work perfectly fine without mod_perl. But how is it going to work under mod_perl, when both mod_perl.so and APR.so will have the same symbols, and according to your suggestion, both will be loaded (since APR/Foo.so will be linked against APR.so). In this approach I don't there's a problem on Windows with linking against libraries with the same symbols; depending on the order of the libraries in the link command, VC++ will resolve the symbols not found in the object files in the 1st library file it finds that has them (which then registers the corresponding .so, if it's a shared library), so any identical symbols in a later library used in the link command are ignored. Thus, you could in principle build an application linked against two dlls that have the same symbols in them and there shouldn't be a conflict, as the application knows, from how it was linked, which dll each symbol comes from. That's excellent. So you link APR/Foo.so against APR.so which contains the minimal amount of modperl_xxx.o in it which is already provided by my patch (you only need to arrange linking against APR.lib instead of mod_perl.lib). APR/Foo.pm then must make sure that APR.pm (and so APR.so) are loaded before it loads its own APR/Foo.so. But this could be done later, for now let's say that we do it manually, by doing PerlModule APR immediately after LoadModule mod_perl.so Now the question is, whether the same could work for all other platforms. I was sure that's it's not possible to load two objects with the same symbols, but I could be wrong. Do you know whether this is true for all platforms? However, this also means that no symbols can be resolved through mod_perl.lib, as this would require loading mod_perl.so (unless one used the -delayload link option, to load the dll only if a symbol is invoked). That's perfectly fine. It would have worked perfectly if we could also link mod_perl.so against APR.so and not include those symbols in mod_perl.so. Which is probably the best solution possible. The problem is that the loaded will somehow have to find APR.so when trying to load mod_perl.so. This could have been done by installing APR.so along with libapr.so I suppose. In that case we will have APR a totally autonomous systems and mod_perl will use it. May be it makes perfect sense, but I haven't thought of the implications for users. It should be relatively straightforward to do the latter (as long as APR.so is built before APR::*). However, with the former, there'd be problems building the individual APR::* modules first, to be used as components in building APR.so, for the same reason that exists now - to build APR::*, one has to specify the library where the symbols are found, and one can't specify a library (APR.so) that hasn't been built yet. But I was talking about building .o objects, not shared libs. and linking those .o objects with APR.so. Will that be a problem too? AFAIK you never need to provide information about shared libs, during compilation time. Is that different on windows? No, you're right - resolving all symbols only is required at link time, so this could be done by just compiling (with -c) the APR::* files to build the object files, and skip building the associated APR::* dlls, as is done now. I think things are becoming clearer to me - thanks. It looks like most of this can be done by fiddling with the compiling/linking commands, without the need (hopefully) of any source code modifications. I'll try it and see. Correct. I think your suggestion at the top is much better that dumping all .o into APR.so. If it works for every platform then we are gold. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]