Re: Missing cast in apreq_escape()
Ville Skyttä [EMAIL PROTECTED] writes: https://bugzilla.redhat.com/170401 Dirk Nehring pointed out a missing cast in apreq_escape() and submitted a patch, see attachment. This appears to bite when using a C++ compiler with apreq_util.h. Thanks, applied as r312985. -- Joe Schaefer
Re: mod_mbox
* Maxime Petazzoni wrote: Actually, I feel that last example makes it a pain in the ass for the rest of us humans to email someone about something. No, because you have the full string From: header displayed : From: Justin Erenkrantz [EMAIL PROTECTED] And I hope the rest of us humans aren't that stupid ... Hmm. What would you do with my address? André Malo [EMAIL PROTECTED]? or with mails where no real-name is given? Or doesn't match the local-part of the mail address at all? I find this a bad idea as well. nd -- Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine beiden Gefährten nicht zu zählen brauchte -- Karl May, Winnetou III Im Westen was neues: http://pub.perlig.de/books.html#apache2
Re: nofollow was Re: mod_mbox
Paul Querna wrote: 2. There are several formats for each mail message (regular, raw, mime). Probably the links to everything other than the standard format should use the rel=nofollow modifier to keep the search engines out. Keeping the robots off of 2/3 of the links could make a big difference in load considering the number of pages on this site. I agree. We don't want Google and friends indexing the raw format, and then ranking it higher than the normal presentation. More importantly, any mail archive without nofollow in the messages becomes a spam magnet. Here's some nice free googlerank for http://dodgy.pills.example.com/?refid=yourstruly -- Nick Kew
Re: Win32 binary distributions 2.1.9-beta and onwards
William A. Rowe, Jr. wrote: Question; I'm looking for input what version of visual c++ we should build apr 1.x and httpd 2.1.x and onwards with. As most are aware, discrepancies in the clib mean that mismatched posix open()/close(), malloc()/free() can all cause serious problems, so a single version is vastly preferable. Open to comments... Are you saying that if you move to something later than VC6, then if I compile modules using VC6 they will no longer work? That sounds like some nasty barriers in the way of those of us who have climbed the windows learning curve just enough to support our own modules outside the apache core distribution. Talking of windows builds, where's mod_ssl seems to be something of a FAQ in user support. Why is it a problem *now* to include it? -- Nick Kew
Re: Win32 binary distributions 2.1.9-beta and onwards
On Tue, Oct 11, 2005 at 02:07:56AM -0500, William A. Rowe, Jr. wrote: I'm looking for input what version of visual c++ we should build apr 1.x and httpd 2.1.x and onwards with. As most are aware, discrepancies in the clib mean that mismatched posix open()/close(), malloc()/free() can all cause serious problems, so a single version is vastly preferable. Open to comments... http://lab.msdn.microsoft.com/express/visualc/default.aspx seems to be able to build httpd (based on half a day of testing anyway), a big disadvantage is that it is in beta, which means - in theory - the clib things could change (unlikely), but a big advantage is that it is free and capable of building httpd, which may significantly help with developer access for httpd/apr on Win32. It's expected to come out of beta by Christmas (though this is MS we're talking about) and go live on the main MSDN site (still free). Another slight downside is that we will probably need to document the build process slightly more, SDK's need to be in the right place and so on, but we need to document the win32 build process pretty badly anyway, some of the procedures are woefully non-intuitive (like hand editing files that have DO NOT HAND EDIT written in them ;-) ) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [pre-release] rpm spec file (was: Re: [pre-release] 2.0.55 *candidate* available for testing)
Luc Pardon said: In that case the 2.0 httpd.spec files should either a) not require pre-installed apr packages and build apr as part of the httpd rpm, A definite -1 on this. If this were so, httpd could not coexist cleanly with other packages that depended on APR. or b) build the bundled apr stuff into separate rpm packages itself. APR is already available as an RPM, both for the 0.9 and 1.x trees, and 0.9 and 1.x can be installed simultaneously. See the binaries/rpm directory in the download section for APR. I'm only really familiar with rpm-ing on RedHat platforms, but AFAIK the rpm specs differ in details, so you'd probably have to populate the rpm subdir with working spec files for various platforms (collected after the fact g). Or add platform-specific subdirs under rpm/. Different spec files for different platforms should be avoided as much as possible. Each distro will release an httpd version + their custom patches for the purposes of that distro anyway, Apache isn't a distro, so can release a clean httpd as is without any patches. The httpd.spec file, as included in the tarball, requires apr and apr-util and the corresponding devel packages to be installed as separate rpm's. Although the APR source code is present in the httpd tarball, there are currently no APR spec files. You can't build the APR rpm's from the httpd.spec file either. In other words, if you want to build httpd from the included spec file, you'll first have to go and find the APR rpm's in the usual places and install them. There are APR spec files in the APR and APR-util archives. They are removed from the apr tree in the httpd build, as rpm gets confused is there is more than one spec file in a tarball (in other words, rpmbuild -tb is not possible otherwise). Most people building rpm's themselves (as opposed to installing pre-built binary rpm's) would IMO be able to cope with that. In fact, I'd expect them to have pre-existing spec files anyway. Therefore, another solution would be to lift httpd.spec out of the 2.0.55 tarball altogether (but that's frozen, right?). If you leave it in, changing the dependencies to properly require 0.9.7 (or newer?) is a trivial change to build/rpm/httpd.spec.in. So trivial in fact that I'm willing to provide a patch g. Please do :) There is one fix I need to make to the httpd.in file as released concerning the xml doc files. The spec file tries to remove the xml files, however the build was changed to remove them. Regards, Graham --
Re: [pre-release] rpm spec file (was: Re: [pre-release] 2.0.55 *candidate* available for testing)
Graham Leggett wrote: Luc Pardon said: In that case the 2.0 httpd.spec files should either a) not require pre-installed apr packages and build apr as part of the httpd rpm, A definite -1 on this. If this were so, httpd could not coexist cleanly with other packages that depended on APR. Definitely. I missed the fact that apr 0.9 and 1.x can coexist. or b) build the bundled apr stuff into separate rpm packages itself. APR is already available as an RPM, both for the 0.9 and 1.x trees, and 0.9 and 1.x can be installed simultaneously. See the binaries/rpm directory in the download section for APR. Yes, but what got me confused is that the httpd tarball comes with the APR source (hence the docs don't talk about it as being a prerequisite) whereas the current spec file requires you to go elsewhere and get something that is already there. It seem to me that this kind of defeats the purposo of bundling APR. I'm only really familiar with rpm-ing on RedHat platforms, but AFAIK the rpm specs differ in details, so you'd probably have to populate the rpm subdir with working spec files for various platforms (collected after the fact g). Or add platform-specific subdirs under rpm/. Different spec files for different platforms should be avoided as much as possible. Each distro will release an httpd version + their custom patches for the purposes of that distro anyway, Apache isn't a distro, so can release a clean httpd as is without any patches. Agreed on both counts. That (no patches) is one of the reasons why I'm building my own. But I think there are sometimes other differencies than just patches, no ? For example, installing into platform-dependent dirs or other variations in configure options ? Or init script stuff ? Note that I'm not arguing, just wondering. Of course, having multiple spec files (for different platforms) will break rpmbuild -tb big time. The httpd.spec file, as included in the tarball, requires apr and apr-util and the corresponding devel packages to be installed as separate rpm's. Although the APR source code is present in the httpd tarball, there are currently no APR spec files. You can't build the APR rpm's from the httpd.spec file either. In other words, if you want to build httpd from the included spec file, you'll first have to go and find the APR rpm's in the usual places and install them. There are APR spec files in the APR and APR-util archives. They are removed from the apr tree in the httpd build, as rpm gets confused is there is more than one spec file in a tarball (in other words, rpmbuild -tb is not possible otherwise). I see. But couldn't you leave them sitting in srclib/apr, where rpmbuild -tb won't see them ? Or better, merge them into httpd.spec, so that rpmbuild -tb will produce apr packages from the bundled code in one go ? Would there be any objections against the latter ? After all, httpd.spec already produces the httpd, httpd-devel, httpd-manual and mod_ssl rpm's. Why not apr, apr-util, apr-devel and apr-util-devel as well ? Nobody obliges you to install the whole set. If you leave it in, changing the dependencies to properly require 0.9.7 (or newer?) is a trivial change to build/rpm/httpd.spec.in. So trivial in fact that I'm willing to provide a patch g. Please do :) From a later message of yours, it seems it's too late already g. As an aside, is there no configure macro somewhere (something like APR_VERSION) that would avoid having to hard-code it in httpd.spec.in ? Luc
Re: [pre-release] 2.0.55 *candidate* available for testing
Colm MacCarthaigh said: How many people actually build RPM's is what I'm wondering, given the errors that creep in in the releases, and we don't see that many complaints, it can't be a very high number. I see a fair amount of downloads for the RPM's files themselves, which is what makes me wonder. We provide SRPMs for building, which contain fixed httpd.spec files. Either that or the i386 builds work as is for people on i386 platforms. I personally deploy from a locally built SRPM, but that's me. Ideally the rpm builds should be continuously integrated using something like gump, so we catch the problem as it happens, rather than after release. I don't think having to un-tar a tarball, and mv a file in place is that big an imposition on a packager. Anything that's non obvious or non standard is definitely an imposition on a packager. Don't make the packager do something that can be (and already is) easily automated :) Regards, Graham --
Re: [pre-release] rpm spec file (was: Re: [pre-release] 2.0.55 *candidate* available for testing)
Luc Pardon said: Yes, but what got me confused is that the httpd tarball comes with the APR source (hence the docs don't talk about it as being a prerequisite) whereas the current spec file requires you to go elsewhere and get something that is already there. It seem to me that this kind of defeats the purposo of bundling APR. The APR bundled with source is historical - the APR library grew out of the httpd code, and was only recently promoted to a library in it's own right. The removal of APR from the httpd has been discussed a number of times, and I think will probably happen eventually once APR is widespread on it's own. Most of the major distros already distribute httpd and apr separately as APR v0.9.x and httpd v2.0.x (Redhat does anyway), so in the RPM world this isn't too much of a surprise to have them separate. Agreed on both counts. That (no patches) is one of the reasons why I'm building my own. But I think there are sometimes other differencies than just patches, no ? For example, installing into platform-dependent dirs or other variations in configure options ? Or init script stuff ? The spec file has slowly got simpler and simpler, with more and more of the special stuff being removed from the spec file, falling back on the normal httpd build process. Ideally the spec file should eventually be trivial, it shouldn't be necessary to have to move files and directories around in a spec file when the httpd build process contains an option to choose a directory layout already. I see. But couldn't you leave them sitting in srclib/apr, where rpmbuild -tb won't see them ? Or better, merge them into httpd.spec, so that rpmbuild -tb will produce apr packages from the bundled code in one go ? There is a drive to get APR to stand on it's own as much as possible. Combining the packaging with httpd is going backwards on a process that should eventually see apr removed from the httpd tree entirely. From a later message of yours, it seems it's too late already g. I just created a patch for this, just battling to test it (stupid working directories copied from MacOSX to Fedora grumble). As an aside, is there no configure macro somewhere (something like APR_VERSION) that would avoid having to hard-code it in httpd.spec.in ? If there is this would be very useful, will have to investigate. Regards, Graham --
Re: [pre-release] 2.0.55 *candidate* available for testing
On Tue, Oct 11, 2005 at 01:34:16PM +0200, Graham Leggett wrote: We provide SRPMs for building, which contain fixed httpd.spec files. I see people downloading them a fair ammount ( 400 per day, which is actually quite a lot for the binaries section), and I don't see why these would discontinue. So, would it be so bad a thing if the release tarball wasn't itself buildable? What is the number of commands it takes to turn an SRPM into a binary .rpm ? Either that or the i386 builds work as is for people on i386 platforms. I personally deploy from a locally built SRPM, but that's me. I deploy a locally built .deb, and that's much more work, so building an rpm locally might be a lot more common than I suspect. Ideally the rpm builds should be continuously integrated using something like gump, so we catch the problem as it happens, rather than after release. +1 I don't think having to un-tar a tarball, and mv a file in place is that big an imposition on a packager. Anything that's non obvious or non standard is definitely an imposition on a packager. Don't make the packager do something that can be (and already is) easily automated :) Well to be honest, I'm kind of confused as to why the source tarball should be doing any of the packager's work, but I guess that's a different argument :-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [pre-release] 2.0.55 *candidate* available for testing
Colm MacCarthaigh said: I see people downloading them a fair ammount ( 400 per day, which is actually quite a lot for the binaries section), and I don't see why these would discontinue. So, would it be so bad a thing if the release tarball wasn't itself buildable? The release tarball should in itself be buildable, yes. Trouble is I sometime don't get to test the RPM build on time, and the release goes out the door with a broken spec file :( What is the number of commands it takes to turn an SRPM into a binary .rpm ? rpmbuild --rebuild httpd-2.0.55-1.src.rpm I deploy a locally built .deb, and that's much more work, so building an rpm locally might be a lot more common than I suspect. We currently have build scripts/spec file for RPM and for Solais PKG, is it difficult to get httpd to be built as a .deb out the box? I know precious little about .deb packaging. Well to be honest, I'm kind of confused as to why the source tarball should be doing any of the packager's work, but I guess that's a different argument :-) RPM has features that make it easy to go from tarball to RPM in a single step, and follows the principle of least astonishment :) Regards, Graham --
Re: [PATCH] Bug 36816: balancer_manager doesn't work if worker name contains port
On Oct 10, 2005, at 5:13 PM, Ruediger Pluem wrote: On 10/10/2005 05:43 PM, Jim Jagielski wrote: For consideration: [..cut..] Thanks for your thoughts. BTW: It was a little bit tricky to apply the patch as my Mozilla seems to have changed things in the mail spaces / empty lines. So I guess attached patches are easier to handle :-). I think I found one big problem with the patch: When we call ap_proxy_get_worker in line 1316 of proxy_util.c (ap_proxy_pre_request), then the parameter url already contains the complete URL we must call on the remote server. Example: ServerName example.com ProxyPass /mirror/foo http://backend.com/rsync This would result in a worker named http://backend.com/rsync Calling http://example.com/mirror/foo/bar would be translated to proxy:http://backend.com/rsync/bar in the translate_name hook of mod_proxy. Thus ap_proxy_get_worker would be called with the URL http:// backend.com/rsync/bar which would lead to a no match. I guess instead of a simple strcasecmp we need something like a longest match here since I think we cannot rely on the order the workers got stored. Yes, I was also considering that case as well; I simply wanted to give people a head's up on the direction the solution was taking in order to get prelim feedback.
Re: nofollow was Re: mod_mbox
Nick Kew wrote: Paul Querna wrote: 2. There are several formats for each mail message (regular, raw, mime). Probably the links to everything other than the standard format should use the rel=nofollow modifier to keep the search engines out. Keeping the robots off of 2/3 of the links could make a big difference in load considering the number of pages on this site. I agree. We don't want Google and friends indexing the raw format, and then ranking it higher than the normal presentation. More importantly, any mail archive without nofollow in the messages becomes a spam magnet. Here's some nice free googlerank for http://dodgy.pills.example.com/?refid=yourstruly Well, we don't want to keep search engines out of the archive entirely. The archives are a huge resource that we want easily searchable. But we need to start thinking about a way to remove specific messages from our archives for this reason among others. That is more a topic for infrastructure@ Joshua.
Re: nofollow was Re: mod_mbox
On Tuesday 11 October 2005 15:05, Joshua Slive wrote: More importantly, any mail archive without nofollow in the messages becomes a spam magnet. Here's some nice free googlerank for http://dodgy.pills.example.com/?refid=yourstruly Well, we don't want to keep search engines out of the archive entirely. The archives are a huge resource that we want easily searchable. Yes, of course! But we need to start thinking about a way to remove specific messages from our archives for this reason among others. That is more a topic for infrastructure@ But it's not just that. If we have links from the messages, that in itself attracts the spammers! No matter whether we keep spam completely out by moderating the lists, do cleanup after the event, or do nothing, we should avoid offering major incentives to spammers. -- Nick Kew
Re: [PATCH] Bug 36816: balancer_manager doesn't work if worker name contains port
On Oct 10, 2005, at 5:13 PM, Ruediger Pluem wrote: 2. The xml output is currently broken as it only works with schema and hostname. I am not quite sure if 1. there is an xml schema already defined for this and needs to be adjusted 2. we need to parse the worker name and replace some of the characters with xml entities. I think we need to fix this or if not at least a remark in the documentation should be made that the xml output is currently broken. Not sure what the (original) intent of the XML format was or is, but I'm assuming that the current implementation is sufficient.
Re: Win32 binary distributions 2.1.9-beta and onwards
Nick Kew wrote: William A. Rowe, Jr. wrote: Talking of windows builds, where's mod_ssl seems to be something of a FAQ in user support. Why is it a problem *now* to include it? You can find some of that discussion burried in legal-discuss@, while the new VP of legal affairs is taking up the issue. One decision to be made by the project is; will -we- ship openssl binaries? Or the module built against some .dll versions available on www.openssl.org? Bill
Re: [pre-release] 2.0.55 *candidate* available for testing
Graham Leggett wrote: William A. Rowe, Jr. said: The problem is that packaging is almost a 20/20 hindsite game. There's no way we should expect that all of these many platform specifics can all be maintained pre-release. That's why, in the Win32 .msi case, there is a seperate httpd/httpd/win32-msi/trunk/ containing the win32 packaging flavor. It doesn't get fixed for a specific release until we know exactly what needed to be fixed :) I'm concerned that the current .spec solution is wrong; it's very platform specific (platform meaning deployment mechanics, in this case, I'm not slamming non-unix rpm implementations). Perhaps we rejigger the tree to httpd/ package/ roll-release/ win32-msi/ rpm/ pkg/ Thoughts? The spec file needs to end up as httpd.spec in the root of the tarball so that rpmbuild -tb httpd-2.0.55.tar.gz works, so keeping it in a separate tree isn't going to work properly. The problem remains though - people change stuff within the tree, which affects the packaging, and this only surfaces when a release is rolled. So... is it unreasonable in README.RPM to point the user to obtain the current httpd.spec/httpd.in from /dist/httpd/httpd-2.0.55-rpm-src.tar.gz which would be grabbed from svn httpd/package/rpm/, and drop it into the unpacked httpd-2.0.55 source tarball, in order to package? Bill
Re: Win32 binary distributions 2.1.9-beta and onwards
On Tue, 11 Oct 2005, William A. Rowe, Jr. wrote: Question; I'm looking for input what version of visual c++ we should build apr 1.x and httpd 2.1.x and onwards with. As most are aware, discrepancies in the clib mean that mismatched posix open()/close(), malloc()/free() can all cause serious problems, so a single version is vastly preferable. Open to comments... One aspect worth considering is the interaction with Perl, and the fact that the dominant Win32 binary distribution from ActiveState is compiled with VC++ 6. I would expect there to be problems with the mod_perl module if one uses ActiveState's Perl and an Apache compiled with something other than VC++ 6. Might there be problems using such a Perl in a cgi script with a non-VC++ 6 Apache? Of course, one is not restricted to using ActiveState's Perl, but could instead use some other freely available binary. However, ActiveState supplies with their ActivePerl some proprietary tools (ppm, for installing binary packages, and some related tools for managing html docs), which users have come to heavily rely on. Having said that, within the Perl world there is also pressure to migrate to a binary based on a freely available, and more recent, VC++ (but, hopefully, not tied to a particular msvcr dll version). It would be ideal if Apache and ActiveState could coordinate such a migration; however, from ActiveState's point of view, this might not be a consideration until the next major release of perl (5.10), as this most likely won't be binary-comaptible with the current (5.8) version. -- best regards, randy kobes
Re: Win32 binary distributions 2.1.9-beta and onwards
On Tuesday 11 October 2005 17:02, William A. Rowe, Jr. wrote: One decision to be made by the project is; will -we- ship openssl binaries? Or the module built against some .dll versions available on www.openssl.org? Surely, the latter, and point to it in our docs! Datapoint: mod_proxy_html has prerequisites: libxml2 on all platforms, and additional ones on windows. Although I get questions on all levels - from the dumb newbie to the new insight - confusion over the required libs is not an issue. Sufficiently clear documentation works! In the case of mod_ssl, that probably means something in the installer that tells them they need openssl, and where to get it if necessary. -- Nick Kew
Re: mod_mbox
Justin Erenkrantz wrote: 3. We should probably turn on the email-address-obfiscation feature. I personally would prefer if everyone could just use proper spam filtering, but I think the general expectation nowadays is that we try to avoid displaying raw addresses. I think this feature is lame (and said so when it was proposed). Spammers are just going to de-obfuscate anyway. Enabling this provides a false layer of security that does no one any good. As has been pointed out, this is a trade off. You can get real protection at the cost of losing the ability to find real email addresses. Or you can get protection that will work against 95% or more of current web-robots and worms with a simple but reversible obfiscation. I favor the latter, but mod_mbox currently provides only the former. Although I agree with Justin in principle, the fact is that we are one of a very small number of major archives that provide unobfiscated email addresses. As such, we are a major draw for worms and address harvesters. Is this really an area where we want to stand out? Joshua.
Re: Win32 binary distributions 2.1.9-beta and onwards
Randy Kobes wrote: On Tue, 11 Oct 2005, William A. Rowe, Jr. wrote: Question; I'm looking for input what version of visual c++ we should build apr 1.x and httpd 2.1.x and onwards with. As most are aware, discrepancies in the clib mean that mismatched posix open()/close(), malloc()/free() can all cause serious problems, so a single version is vastly preferable. Open to comments... One aspect worth considering is the interaction with Perl, and the fact that the dominant Win32 binary distribution from ActiveState is compiled with VC++ 6. I would expect there to be problems with the mod_perl module if one uses ActiveState's Perl and an Apache compiled with something other than VC++ 6. Might there be problems using such a Perl in a cgi script with a non-VC++ 6 Apache? This is one of my main considerations. Another, of course, is the ActiveState distribution of python ;-) 2.3 is based upon VC6, IIRC, while 2.4 is now being built using either .NET or .NET 2003 (I need to actually double check that.) And as more and more libraries drift from cl.exe rev 12.0, we are going to have to make a jump. The first release of httpd-2.2 seems like the logical point, since it's a clear deliniation. I like the comments about the C++ express flavor, however it's not quite here. [FYI, if we do decide - I can always build our betas on the beta of VS2005, but we would potentially be waiting to ship 2.2 GA]. My bigger concern, and would appreciate any comments, is that the .NET flavors (original, 2003, 2005) seem to keep ditching their clib. Over, and over, and over. I've never had much success shooting clay pidgeons in real life or in software development. Bill Bill
Re: [PATCH] Bug 36816: balancer_manager doesn't work if worker name contains port
On 10/11/2005 04:33 PM, Jim Jagielski wrote: On Oct 10, 2005, at 5:13 PM, Ruediger Pluem wrote: [..cut..] Not sure what the (original) intent of the XML format was or is, but I'm assuming that the current implementation is sufficient. As it is an undocumented feature right now and the intention is also unclear to me I tend now to leave it as it is. Just tried to make some noise about it to find out if somebody knows more about it, so a change here is not forgotten unintentionally. Regards Rüdiger
Re: mod_mbox
--On October 11, 2005 1:24:22 PM -0400 Joshua Slive [EMAIL PROTECTED] wrote: As has been pointed out, this is a trade off. You can get real protection at the cost of losing the ability to find real email addresses. Or you can get protection that will work against 95% or more of current web-robots and worms with a simple but reversible obfiscation. I favor the latter, but mod_mbox currently provides only the former. Well, mod_mbox does have the feature (even though I disagree with it). Although I agree with Justin in principle, the fact is that we are one of a very small number of major archives that provide unobfiscated email addresses. As such, we are a major draw for worms and address harvesters. Is this really an area where we want to stand out? We're not lemmings: we don't have to follow what others do. I got spam well before we ever had public web archives hosted on apache.org... -- justin
[Fwd: [PATCH] worker status change during creation of backend proxy connection]
Just a ping. Anybody found some time to look into the issue below?
Thanks and regards
Rüdiger
Original Message
Subject: [PATCH] worker status change during creation of backend proxy
connection
Date: Mon, 03 Oct 2005 14:29:13 +0200
From: Ruediger Pluem [EMAIL PROTECTED]
Reply-To: dev@httpd.apache.org
To: dev@httpd.apache.org
Hi,
I noticed that the status of a connection (or better for a worker score)
is changed back to SERVER_BUSY_READ from SERVER_BUSY_WRITE, if this connection
requires that mod_proxy creates a new connection to a backend. This does not
happen
if mod_proxy can pick up a connection to this backend from the connection pool.
This is a hint to me that the behaviour in the situation where a new connection
gets
created is not correct.
I see two problems with the current behaviour:
1. mod_status shows the wrong status.
2. It is hard for functions in the pre_connection hook to decide if they are
called
for an outgoing proxy connection or for an incoming client connection.
For sure for some this does not matter, but for others it does.
If the status of the connection would not be changed they could determine
this
by checking if the status is SERVER_BUSY_READ (client connection) or
SERVER_BUSY_WRITE (proxy connection to backend).
The reason for the status change is the execution of the create_connection hook
in ap_proxy_connection_create in proxy_util.c and thus the execution of
core_create_conn in core.c.
So my idea is to save the scoreboard entry for this slot before calling the
create_connection hook and restore it afterwards. If this is is not a solution
for the problem I fear that some refactoring of the connection creation process
in
mod_proxy is needed.
Below there is a patch which does what I described. As struct ap_sb_handle_t is
private data to scoreboard.c, I created a small function that allows me to get
the
pointer to worker_score based on the scoreboard handle.
I am not totally happy with the name of this function
(ap_get_scoreboard_worker_sbh),
so any proposals for a different name are welcome.
Comments / thoughts?
Regards
Rüdiger
Index: server/scoreboard.c
===
--- server/scoreboard.c»(Revision 292553)
+++ server/scoreboard.c»(Arbeitskopie)
@@ -476,6 +476,13 @@
return ap_scoreboard_image-servers[x][y];
}
·
+AP_DECLARE(worker_score *) ap_get_scoreboard_worker_sbh(ap_sb_handle_t *sbh)
+{
+if (!sbh)
+return(NULL);
+return ap_get_scoreboard_worker(sbh-child_num, sbh-thread_num);
+}
+
AP_DECLARE(process_score *) ap_get_scoreboard_process(int x)
{
if ((x 0) || (server_limit x)) {
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c»·(Revision 292553)
+++ modules/proxy/proxy_util.c»·(Arbeitskopie)
@@ -1995,13 +1995,35 @@
{
apr_sockaddr_t *backend_addr = conn-addr;
int rc;
+/* Pointer to scoreboard entry of current worker */
+worker_score *current_worker_score;
+/* Saves scoreboard entry of current worker temporarily */
+worker_score current_worker_score_save;
·
+/*
+ * As ap_run_create_connection modifies the scoreboard entry for the
+ * current worker, save the whole scoreboard entry for this worker
+ * and restore it after ap_run_create_connection has been run.
+ * Apart from the fact that mod_status will display correct information
+ * again it makes it possible for functions in the
+ * ap_run_pre_connection to check whether they are called for
+ * a mod_proxy connection or for an incoming connection by just checking
+ * the status of the current worker (whether its SERVER_BUSY_READ
+ * or SERVER_BUSY_WRITE).
+ */
+current_worker_score = ap_get_scoreboard_worker_sbh(c-sbh);
+memcpy(current_worker_score_save, current_worker_score,
+ sizeof(worker_score));
+
/* The socket is now open, create a new backend server connection·
*·
*/
conn-connection = ap_run_create_connection(c-pool, s, conn-sock,
c-id, c-sbh,
c-bucket_alloc);
+/* Restore scoreboard entry for current worker */
+memcpy(current_worker_score, current_worker_score_save,
+ sizeof(worker_score));
·
if (!conn-connection) {
/* the peer reset the connection already; ap_run_create_connection()·
Index: include/scoreboard.h
===
--- include/scoreboard.h»···(Revision 292553)
+++ include/scoreboard.h»···(Arbeitskopie)
@@ -190,6 +190,7 @@
void ap_time_process_request(ap_sb_handle_t *sbh, int status);
·
AP_DECLARE(worker_score *) ap_get_scoreboard_worker(int x, int y);
+AP_DECLARE(worker_score *) ap_get_scoreboard_worker_sbh(ap_sb_handle_t *sbh);
AP_DECLARE(process_score *) ap_get_scoreboard_process(int x);
Re: [PATCH] Bug 36816: balancer_manager doesn't work if worker name contains port
On Oct 11, 2005, at 3:13 PM, Ruediger Pluem wrote: Sorry, too impatient again :-(. Nevertheless apart from the xml stuff, any comments about the latest version of the patch I attached yesterday? +1... I haven't looked to see if there's a better way to do the 'longest match' test, but that's nit picking :)
Re: [PATCH] Bug 36816: balancer_manager doesn't work if worker name contains port
On 10/11/2005 09:56 PM, Jim Jagielski wrote: [..cut..] +1... I haven't looked to see if there's a better way to do the 'longest match' test, but that's nit picking :) Ok, thanks. I think I will commit it tomorrow to trunk and 2.2.x. Regards Rüdiger
Re: [PATCH] Bug 36816: balancer_manager doesn't work if worker name
Ruediger Pluem wrote: On 10/11/2005 09:56 PM, Jim Jagielski wrote: [..cut..] +1... I haven't looked to see if there's a better way to do the 'longest match' test, but that's nit picking :) Ok, thanks. I think I will commit it tomorrow to trunk and 2.2.x. I can do it if you like... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [PATCH] Bug 36816: balancer_manager doesn't work if worker name
On 10/11/2005 11:22 PM, Jim Jagielski wrote: Ruediger Pluem wrote: On 10/11/2005 09:56 PM, Jim Jagielski wrote: [..cut..] +1... I haven't looked to see if there's a better way to do the 'longest match' test, but that's nit picking :) Ok, thanks. I think I will commit it tomorrow to trunk and 2.2.x. I can do it if you like... You did :). Thanks. Just saw it on #httpd-dev. BTW: Never seen you there so far. Regards Rüdiger
Re: [PATCH] Bug 36816: balancer_manager doesn't work if worker name
=?UTF-8?B?UsO8ZGlnZXIgUGzDvG0=?= wrote: Just saw it on #httpd-dev. BTW: Never seen you there so far. I hate IRC. It's a real time sinkhole :) Plus, it avoids the danger of doing development on IRC instead of on the mailing lists where it belongs... I occasionally am on IM and IRC however, but rarely :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [PATCH] Bug 36816: balancer_manager doesn't work if worker name
On 10/11/2005 11:51 PM, Jim Jagielski wrote: I hate IRC. It's a real time sinkhole :) Plus, it avoids the danger of doing development on IRC instead of on the mailing lists where it belongs... I occasionally am on IM and IRC however, but rarely :) All very true :-). BTW: I just noticed that c = strchr(url, ':'); if (c == NULL || c[1] != '/' || c[2] != '/' || c[3] == '\0') return NULL; in ap_proxy_get_worker of proxy_util.c seem to be unneeded now (Only came to my mind as I saw your commit mail, weird. ) If you agree I will remove them tomorrow as a clean-up. Regards Rüdiger
DO NOT REPLY [Bug 32658] - mod_aspdotnet returns stale cached files
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32658. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32658 --- Additional Comments From [EMAIL PROTECTED] 2005-10-12 00:09 --- Hi, im having this problem. I get it after a much shorter duration though, nearer 15 minutes. Sometimes I get a default apache error page, it just says there has been a server error without getting into details. After that point (or without the error page) it uses old cached versions of all the .aspx files. I can delete the file and still get the old cached one. I would like to try the build that you posted but the links dead now. I've tried loads of things to prevent caching. Tried programatically turning it off in c#, then tried doing in on the page with: %@ OutputCache Duration=1 VaryByParam=None Location=None % then enabled apaches mod_expires module and stuck the following in a fresh .htaccess file: ExpiresActive on ExpiresDefault access i tried tinkering in the machine.config file as well. nothing works. its really frustrating because i'm working on a site at home directly on the server so i might be saving it every 5 minutes to check changes. now i have to keep commenting things out or putting obvious coding errors in every few minutes and re-running it all to see if its using cached copies or the bits i've just written/commented out. the only fix i've found that works is to restart apache but thats a pain as i have to do it every 15-20 minutes all day long, it also means lots of running up and down stairs to get to the server :¬) the main reason restarting apache is a pain though is because i host some small sites for other people and every now and then one of them rings up and says how come my site keeps going down?. thanks for mod_aspdotnet, it is really cool to be able to use .net with apache on windows. this is the only thing thats spoiling the fun for me. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [PATCH] Bug 36816: balancer_manager doesn't work if worker name
Ruediger Pluem wrote: On 10/11/2005 11:51 PM, Jim Jagielski wrote: I hate IRC. It's a real time sinkhole :) Plus, it avoids the danger of doing development on IRC instead of on the mailing lists where it belongs... I occasionally am on IM and IRC however, but rarely :) All very true :-). BTW: I just noticed that c = strchr(url, ':'); if (c == NULL || c[1] != '/' || c[2] != '/' || c[3] == '\0') return NULL; in ap_proxy_get_worker of proxy_util.c seem to be unneeded now (Only came to my mind as I saw your commit mail, weird. ) If you agree I will remove them tomorrow as a clean-up. It's a quick way, I think, I avoiding bogus urls (one's that lack schemes) without wasting time with the various strncasecmps. Of course, that get's me thinking... maybe strncmp() is more correct. We want to be case ignorant with hostname but NOT with path. And, iirc, we force the hostname in name to be lowercase. Let me look into that :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Should exist: mod_log_dbus?
(Apologies for posting here and on the modules list - it just occured to me that this might be a better place) I'm playing around with log analysis at the moment - particularly real time analysis. Currently I just pipe logs through a Perl script that does the actual analysis. I'd quite like to be able to have multiple filters analysing the incoming log entries at the same time. I can of course do that just by building a pipeline of filters - but it starts to get messy. So, I was looking at d-bus [1] and thinking how convenient it would be if I had a d-bus based logging module. Then I could just write filters that subscribed to the log messages. I could easily add, remove and restart filters without touching Apache. I'm prepared to do some work on such a module but I don't want to do it if there's some obvious alternative I'm missing. Is this something that might be useful? Is there something out there already that I've missed? [1] http://www.freedesktop.org/Software/dbus -- Andy Armstrong, hexten.net
mod_mbox and atom 1.0
I note that mod_mbox now produces Atom 1.0 feeds. Excellent! = = = There is a feedvalidator that can be used to identify areas of improvement. http://www.feedvalidator.org/ The highest priority is to make sure that the encoding is correct. As it currently stands, many of these feeds are not well formed XML, meaning that they will be rejected by conformant XML parsers. Fixing this will improve the usability of the HTML pages. An outline of what needs to be done can be found here: http://intertwingly.net/stories/2005/09/28/xchar.rb This is in Ruby. I can translate to C any portions you may have questions on. = = = There also is a minor issue regarding canonicalization. Also, email addresses should be split out from the name (I'll go fix the feedvalidator to issue warnings on this). Finally, it is clear that the authors of mod_mbox know a thing or two about CSS. Such techniques can also be applied to feeds. Take a look at mine for an example, which I am sure you can improve on: http://intertwingly.net/blog/index.atom - Sam Ruby
Re: mod_mbox and atom 1.0
Sam Ruby wrote: The highest priority is to make sure that the encoding is correct. As it currently stands, many of these feeds are not well formed XML, meaning that they will be rejected by conformant XML parsers. Fixing this will improve the usability of the HTML pages. An outline of what needs to be done can be found here: http://intertwingly.net/stories/2005/09/28/xchar.rb This is in Ruby. I can translate to C any portions you may have questions on. Well, this is actually a small part of the whole encoding problem. Right now mod_mbox does *no* encoding translation. We really need to be calling apr_xlate all over, and turning everything into UTF-8 First. Currently, each item is encoded in whatever the client program sent it as... which isn't good. There also is a minor issue regarding canonicalization. Also, email addresses should be split out from the name (I'll go fix the feedvalidator to issue warnings on this). Yep, I saw that part of the spec, but I was just being lazy when I wrote the atom stuff.
Re: Notice of Intent: TR 1.3.34
On Mon, Oct 10, 2005 at 10:54:36AM -0400, Jim Jagielski wrote: I will be TR'ing 1.3.34 On Tues or Weds May I humbly request inclusion of a patch I wrote almost a year ago? http://issues.apache.org/bugzilla/show_bug.cgi?id=31858 |31858|New|Maj|2004-10-22|regular expression matching broken on amd64 It is not a feature request; it fixes a crashing bug on AMD64. This has been discussed, has been validated, and is included in Gentoo (http://bugs.gentoo.org/show_bug.cgi?id=70177) and probably other distributions. BTW, if the ASF is looking for help better maintaining the 1.3 tree, I am sure that there are a few people on this list, myself included, who would volunteer. Cheers, Glenn
Re: Notice of Intent: TR 1.3.34
Glenn Strauss wrote: On Mon, Oct 10, 2005 at 10:54:36AM -0400, Jim Jagielski wrote: I will be TR'ing 1.3.34 On Tues or Weds May I humbly request inclusion of a patch I wrote almost a year ago? http://issues.apache.org/bugzilla/show_bug.cgi?id=31858 |31858|New|Maj|2004-10-22|regular expression matching broken on amd64 It is not a feature request; it fixes a crashing bug on AMD64. This has been discussed, has been validated, and is included in Gentoo (http://bugs.gentoo.org/show_bug.cgi?id=70177) and probably other distributions. +1 BTW, if the ASF is looking for help better maintaining the 1.3 tree, I am sure that there are a few people on this list, myself included, who would volunteer. Help is always welcome, but as we approach 2.2 (meaning 2.0-final), we draw closer and closer to EOL for Apache 1.3 support. Sure, it will probably be still supported for security holes (considering all the very interesting oddball architectures that aren't supported by our libtool friends) - but will it be any more frequent than 1x to 2x a year? Not likely :) Bill
RE: Notice of Intent: TR 1.3.34
And frankly it's about damn time. There are a variety of corporate product deployments still using various bastardized versions of the apache 1.3 tree. It's disgusting the number of security holes that these often latent-version derivatives induce without any kind of secondary access controls implemented by default. Further, hopefully the true EOL will force some of our development colleagues *cough* to focus more attention onto optimizing module integrations for efficient usage of the 2.0 and beyond infrastructure. While I am at it... is much being looked at for optimization under GCC 4.1 in future releases? Thinking specifically in terms of optimizing algorithmic methods / looping for vectorized execution given the industry's move towards multi-path programming and execution models. At present we have moved from SMP to environments where we are looking at dual-core and even now (with some of the server platforms being developed using the cell processor) true vectorized execution. -- Wayne S. Frazee Ita erat quando hic adventi. -- Help is always welcome, but as we approach 2.2 (meaning 2.0-final), we draw closer and closer to EOL for Apache 1.3 support. Sure, it will probably be still supported for security holes (considering all the very interesting oddball architectures that aren't supported by our libtool friends) - but will it be any more frequent than 1x to 2x a year? Not likely :) Bill
Re: mod_mbox
Garrett Rooney wrote: It just comes down to two questions. Do we want to offer the service, and if so, what resource utilization do we want to optimize for? If they are running an atom client, is it unreasonable to also force mod_deflate upon them to further conserve bandwidth? IIUC, with mod_cache running, the deflated results themselves would be cached, keeping the cpu zlib cycles down. Bill
Re: mod_mbox
Paul Querna wrote: Hell, if we want to optimize for bandwidth, we really should enable mod_deflate, which is pretty damn effective Someday I'll start using the exciting read-ahead features of Firefox. (read: down arrow key :-)
Re: mod_mbox
On 10/10/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Garrett Rooney wrote: It just comes down to two questions. Do we want to offer the service, and if so, what resource utilization do we want to optimize for? If they are running an atom client, is it unreasonable to also force mod_deflate upon them to further conserve bandwidth? IIUC, with mod_cache running, the deflated results themselves would be cached, keeping the cpu zlib cycles down. I'm honestly not sure what percentage of feed readers support mod_deflate. Considering the percentage that don't support If-Modified-Since and If-None-Match, I'm not optimistic though... -garrett
Win32 binary distributions 2.1.9-beta and onwards
Question; I'm looking for input what version of visual c++ we should build apr 1.x and httpd 2.1.x and onwards with. As most are aware, discrepancies in the clib mean that mismatched posix open()/close(), malloc()/free() can all cause serious problems, so a single version is vastly preferable. Open to comments... Bill
[pre-release] rpm spec file (was: Re: [pre-release] 2.0.55 *candidate* available for testing)
William A. Rowe, Jr. wrote: snip This was a snafu in the way the rpm change was presented, not in the tarballs. httpd-2.0's distribution tarball will always contain apr 0.9. That doesn't mean httpd-2.2 (with apr 1.x) will do the same; that's yet to be determined. In that case the 2.0 httpd.spec files should either a) not require pre-installed apr packages and build apr as part of the httpd rpm, or b) build the bundled apr stuff into separate rpm packages itself. Solution a) would be best if httpd 2.0.55 absolutely requires apr 0.9.7 and nothing else, i.e. does not work with apr 1.2.1 or not even with 0.9.8 if/when that comes out. Otherwise, solution b) would be the way to go. Again, I realize that all this has been discussed at length on this list. Normally I would look at the archives but the countdown has started and my time is limited, so it's quicker to ask. For me, that is ... Coming back to rpm's for the moment; I do *not* mean to suggest that this is the best solution for any specific platform or distribution method, be it .rpm, .depot, .pkg, .msi, or any other facility. Wise, very. Any suggestion in that area is likely to spark a flame war g. snip I'm concerned that the current .spec solution is wrong; it's very platform specific (platform meaning deployment mechanics, in this case, I'm not slamming non-unix rpm implementations). Perhaps we rejigger the tree to httpd/ package/ roll-release/ win32-msi/ rpm/ pkg/ Thoughts? Not really. The current build/rpm seems fine to me, but I wouldn't mind if it changed either. I'm only really familiar with rpm-ing on RedHat platforms, but AFAIK the rpm specs differ in details, so you'd probably have to populate the rpm subdir with working spec files for various platforms (collected after the fact g). Or add platform-specific subdirs under rpm/. In the interim; is this a showstopper? Do we generally do the right thing (e.g. without changes, can we package up using the existing rpm files?) Obviously 2.0.54 was mispackaged as well, it's minimum apr package dependency should have been 0.9.6 apr, not 0.9.5. Bill Showstopper probably not, as long as you document that the spec file is broken, for example: The httpd.spec file, as included in the tarball, requires apr and apr-util and the corresponding devel packages to be installed as separate rpm's. Although the APR source code is present in the httpd tarball, there are currently no APR spec files. You can't build the APR rpm's from the httpd.spec file either. In other words, if you want to build httpd from the included spec file, you'll first have to go and find the APR rpm's in the usual places and install them. Most people building rpm's themselves (as opposed to installing pre-built binary rpm's) would IMO be able to cope with that. In fact, I'd expect them to have pre-existing spec files anyway. Therefore, another solution would be to lift httpd.spec out of the 2.0.55 tarball altogether (but that's frozen, right?). If you leave it in, changing the dependencies to properly require 0.9.7 (or newer?) is a trivial change to build/rpm/httpd.spec.in. So trivial in fact that I'm willing to provide a patch g. Beyond that, any fix I can offer (e.g. to build separate apr packages) would only be tested on my systems. Luc Pardon
Re: mod_mbox
* Paul Querna [EMAIL PROTECTED] [2005-10-10 22:57:44]: Maxime Petazzoni wrote: * Justin Erenkrantz [EMAIL PROTECTED] [2005-10-10 22:33:16]: 3. We should probably turn on the email-address-obfiscation feature. I personally would prefer if everyone could just use proper spam filtering, but I think the general expectation nowadays is that we try to avoid displaying raw addresses. I think this feature is lame (and said so when it was proposed). Spammers are just going to de-obfuscate anyway. Enabling this provides a false layer of security that does no one any good. Ok, you are a spam bot and you don't have the slightest idea of who f*** I am. Now, please, de-obfuscate this : [EMAIL PROTECTED] Or even this : [EMAIL PROTECTED] Actually, I feel that last example makes it a pain in the ass for the rest of us humans to email someone about something. No, because you have the full string From: header displayed : From: Justin Erenkrantz [EMAIL PROTECTED] And I hope the rest of us humans aren't that stupid ... - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. signature.asc Description: Digital signature
