Re: Various musings about the request URL / URI / whatever
Gregory (Grisha) Trubetskoy writes: I think a properly designed site should insist on its host name, i.e. I see you think I'm gobbledygook.bleh, but I'm going to redirect you to http://www.modpython.org/ because that is my true name. This is very common with sites that respond to both www.site.com and site.com, but insist on only one of those by redirecting. As I said in my previous email to the list, I *think* if you use virtual hosts and your real sites are NOT the first real host, then you are forcing clients to speak HTTP/1.1, thus forcing the Host header to be sent. If you then put in your first, default virtualhost: RedirectPermanent / http://realserver/ then you protect yourself from gobbledygook.bleh because that will be sent to the default virtualhost which will redirect. Right? If so, a bit convoluted and not accessible to the novice. Perhaps a Tips Tricks chapter to the manual? Daniel Popowich --- http://home.comcast.net/~d.popowich/mpservlets/
Re: Various musings about the request URL / URI / whatever
Jim Gallacher wrote: Gregory (Grisha) Trubetskoy wrote: I don't know what the specific issue is with parsed_uri, if this is a mod_python bug it should just be fixed BUT if this is an issue with httpd, I don't think we should cover the problem up by having mod_python fix it. Since we are part of the HTTP Server project, we should just fix it in httpd. Either way, it should be fixed. I think maybe it's not really broken. In case anyone is not familiar with the issue, a request for http://example.com/tests/mptest?view=form currently gives a tuple that looks something like this: That's not true. That's what you might see in your client browser, but (usually) it only asks for /tests/mptest?view=form, regardless of the name it used to find the server. It may use the Host: header to negotiate the right virtual host, but the Host: header is not part of the string that parsed_uri is actually parsing. (None, None, None, None, None, None, '/tests/mptest', 'view=form', None) which is not what we expect. This is what the mod_python docs have to say: parsed_uri Tuple. The URI broken down into pieces. (scheme, hostinfo, user, password, hostname, port, path, query, fragment). The apache module defines a set of URI_* constants that should be used to access elements of this tuple. Example: fname = req.parsed_uri[apache.URI_PATH] (Read-Only) This is all correct. I think the problem is that developers are hoping to use parsed_uri in a use case for which it is inappropriate. Those values are populated *if present* in the supplied request URI, but the only *minimal* requirement would be a / for the path. If you want to know what resource the client *really* requested (and inquiring minds do), you *must not* attempt to rewrite or repopulate this.
Re: PHP testing - problem with php libraries loading
Filin A. wrote: But after I read your question I made an experiment whith my system httpd.conf and php.ini and checked phpinfo() output. I've set the extension_dir in php.ini to the wrong directory and assigned correct value in the httpd.conf. It's strange but though phpinfo() acknowledges my httpd.conf extension_dir as a 'Local Value', extensions are not loaded. That rules out Apache-Test as the root cause of the problem. If I were trying to debug this, I'd very carefully compare the output of phpinfo() in an environment that works with the output of phpinfo() in an environment that doesn't. Hope that helps. Chris -- Chris Shiflett Brain Bulb, The PHP Consultancy http://brainbulb.com/
[STATUS] (httpd-test: flood) Wed Nov 30 23:52:58 2005
flood STATUS: -*-text-*- Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $] Release: 1.0: Released July 23, 2002 milestone-03: Tagged January 16, 2002 ASF-transfer: Released July 17, 2001 milestone-02: Tagged August 13, 2001 milestone-01: Tagged July 11, 2001 (tag lost during transfer) RELEASE SHOWSTOPPERS: * Everything needs to work perfectly Other bugs that need fixing: * I get a SIGBUS on Darwin with our examples/round-robin-ssl.xml config, on the second URL. I'm using OpenSSL 0.9.6c 21 dec 2001. * iPlanet sends Content-length - there is a hack in there now to recognize it. However, all HTTP headers need to be normalized before checking their values. This isn't easy to do. Grr. * OpenSSL 0.9.6 Segfaults under high load. Upgrade to OpenSSL 0.9.6b. Aaron says: I just found a big bug that might have been causing this all along (we weren't closing ssl sockets). How can I reproduce the problem you were seeing to verify if this was the fix? * SEGVs when /tmp/.rnd doesn't exist are bad. Make it configurable and at least bomb with a good error message. (See Doug's patch.) Status: This is fixed, no? * If APR has disabled threads, flood should as well. We might want to have an enable/disable parameter that does this also, providing an error if threads are desired but not available. * flood needs to clear pools more often. With a long running test it can chew up memory very quickly. We should just bite the bullet and create/destroy/clear pools for each level of our model: farm, farmer, profile, url/request-cycle, etc. * APR needs to have a unified interface for ephemeral port exhaustion, but aparently Solaris and Linux return different errors at the moment. Fix this in APR then take advantage of it in flood. * The examples/analyze-relative scripts fail when there are less than 5 unique URLs. Other features that need writing: * More analysis and graphing scripts are needed * Write robust tool (using tethereal perhaps) to take network dumps and convert them to flood's XML format. Status: Justin volunteers. Aaron had a script somewhere that is a start. Jacek is working on a Mozilla application, codename Flood URL bag (much like Live HTTP Headers) and small HTTP proxy. * Get chunked encoding support working. Status: Justin volunteers. He got sidetracked by the httpd implementation of input filtering and never finished this. This is a stopgap until apr-serf is completed. * Maybe we should make randfile and capath runtime directives that come out of the XML, instead of autoconf parameters. * We are using apr_os_thread_current() and getpid() in some places when what we really want is a GUID. The GUID will be used to correlate raw output data with each farmer. We may wish to print a unique ID for each of farm, farmer, profile, and url to help in postprocessing. * We are using strtol() in some places and strtoll() in others. Pick one (Aaron says strtol(), but he's not sure). * Validation of responses (known C-L, specific strings in response) Status: Justin volunteers * HTTP error codes (ie. teach it about 302s) Justin says: Yeah, this won't be with round_robin as implemented. Need a linked list-based profile where we can insert new URLs into the sequence. * Farmer (Single-thread, multiple profiles) Status: Aaron says: If you have threads, then any Farmer can be run as part of any Farm. If you don't have threads, you can currently only run one Farmer named Joe right now (this will be changed so that if you don't have threads, flood will attempt to run all Farmers in serial under one process). * Collective (Single-host, multiple farms) This is a number of Farms that have been fork()ed into child processes. * Megaconglomerate (Multiple hosts each running a collective) This is a number of Collectives running on a number of hosts, invoked via RSH/SSH or maybe even some proprietary mechanism. * Other types of urllists a) Random / Random-weighted b) Sequenced (useful with cookie propogation) c) Round-robin d) Chaining of the above strategies Status: Round-robin is complete. * Other types of reports Status: Aaron says: simple reports are functional. Justin added a new type that simply prints the approx. timestamp when the test was run, and the result as OK/FAIL; it is called easy reports (see flood_easy_reports.h).
[STATUS] (httpd-test: perl-framework) Wed Nov 30 23:54:11 2005
httpd-test/perl-framework STATUS: -*-text-*- Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $] Stuff to do: * finish the t/TEST exit code issue (ORed with 0x2C if framework failed) * change existing tests that frob the DocumentRoot (e.g., t/modules/access.t) to *not* do that; instead, have Makefile.PL prepare appropriate subdirectory configs for them. Why? So t/TEST can be used to test a remote server. * problems with -d perl mode, doesn't work as documented Message-ID: [EMAIL PROTECTED] Date: Sat, 20 Oct 2001 12:58:33 +0800 Subject: Re: perldb Tests to be written: * t/apache - simulations of network failures (incomplete POST bodies, chunked and unchunked; missing POST bodies; slooow client connexions, such as taking 1 minute to send 1KiB; ...) * t/modules/autoindex - something seems possibly broken with inheritance on 2.0 * t/ssl - SSLPassPhraseDialog exec: - SSLRandomSeed exec:
Problem building httpd 2.0.55 with openssl 0.9.8a
[Aside - I posted a similar query to the users list and got a couple of suggestions but no solution, so I'm reposting here] In brief: I'm trying to build http 2.0.55 against openssl 0.9.8a. I've built (but not installed) a local copy of openssl, with shared libraries. I've built http like this: cd httpd-2.0.55/ ./configure \ --prefix=/usr/local/apache2-ssl\ --with-ssl=/home/stephen/apache/openssl-0.9.8a \ --enable-mods-shared=all \ --enable-ssl make make install i.e. with an attempt to link it against the openssl libs in the indicated directory. httpd build and installs fine, but when I try to start it I get this: [EMAIL PROTECTED] $ bin/apachectl startssl Syntax error on line 251 of /usr/local/apache2-ssl/conf/httpd.conf: Cannot load /usr/local/apache2-ssl/modules/mod_ssl.so into server: /usr/local/apache2-ssl/modules/mod_ssl.so: undefined symbol: X509_STORE_CTX_set_depth and ldd shows that bin/httpd is linking against openssl 0.9.7 in /usr/lib: [EMAIL PROTECTED] $ ldd bin/httpd linux-gate.so.1 = (0xe000) libssl.so.0.9.7 = /usr/lib/libssl.so.0.9.7 (0x40018000) libcrypto.so.0.9.7 = /usr/lib/libcrypto.so.0.9.7 (0x40048000) ... However, I'm baffled as to how I can get it to link against my local openssl-0.9.8a libraries, if not with --with-ssl. Any suggestions ? -- Regards Stephen Collyer Netspinner Ltd
AW: problems with ssl in balance/proxy mode
thx this seems to be the proper fix, but how do i apply it? which tool do i need for patching the sourcecode? sorry for asking such newby questions. i am new to opensourcedevelopment. alos: can u tell me if my way of fixing the problem was wrong and why? what is it with brigades and buckets anyway? they seem to be pretty unrelieable since it is possible to make a bucket that contains a pointer to your local char variable and pass it to another function which gives the pointer to another bucket in another brigade! thats very dangerous - especially since the guy who programmed the code responsible for this bug, used the proper functions which indicate proper use of his data. -Ursprüngliche Nachricht- Von: Ruediger Pluem [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. November 2005 23:26 An: dev@httpd.apache.org Betreff: Re: problems with ssl in balance/proxy mode On 11/29/2005 01:27 PM, Matthias Behrens wrote: hi everyone i am new to this list. since there is no faq available i simple post my request and see what happens. sorry if i miss any rule. i have a apache 2.0 in loadbalncing mode using mod_rewrite and mod_proxy. there have allways been problems with https/ssl requests that where longer than 8192 bytes. [..cut..] I don't get the exact problem right now. Are you using httpd 2.0.55? If yes, please have a look at PR37145 (http://issues.apache.org/bugzilla/show_bug.cgi?id=37145) and the attached patch to fix it. Maybe this hurts you. Regards Rüdiger [..cut..]
Re: OT: performance FUD
Nick Kew wrote: On Tuesday 29 November 2005 20:49, Justin Erenkrantz wrote: --On November 29, 2005 3:40:11 PM -0500 Paul A Houle [EMAIL PROTECTED] wrote: * prefork and worker seem to be about equally fast on linux? Yup - this is because forking and threading are equivalent (by and large) on Linux. That's the conventional wisdom for static stuff. If DBD catches on it'll change. Also, 2.2 proxy stuff works much better with worker in Linux. Anything that uses pooling (apr_reslist) seems to work better under worker. This may be because the fallback (ie, no threads) in most modules is kind of nasty. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: OT: performance FUD
Nick Kew wrote: Hmmm, how about an early adopters page? We could *imply* the organisations by featuring mugshots and brief profiles of both Brian and Colm as having successfully beta-tested 2.1.x in very-high-volume production environments. Perhaps, as long as it wasn't tied directly to turner/cnn. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: OT: performance FUD
Colm MacCarthaigh wrote: Well, lets not even come close to risking that. I'm in the process of having an internal whitepaper I did being sanitized for public consumption. Once that's done -- hopefully this week or next -- everything in it is quotable. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: Problem building httpd 2.0.55 with openssl 0.9.8a
On Wed, Nov 30, 2005 at 10:05:19AM +, Stephen Collyer wrote: [Aside - I posted a similar query to the users list and got a couple of suggestions but no solution, so I'm reposting here] In brief: I'm trying to build http 2.0.55 against openssl 0.9.8a. I've built (but not installed) a local copy of openssl, with shared libraries. I've built http like this: If the previous suggestions didn't help please capture the output of running configure and make from a freshly unpacked tarball and upload them along with the config.log file somewhere. joe
Re: httpd-2.1.7 Connection-pooling Problem w/ ReverseProxy, Loadbalancer
Jim Jagielski [EMAIL PROTECTED] writes:
Can you try HEAD on httpd-trunk for a fix until something
more robust as far as the connections are implemented...
It gets the backend-connections right, but segfaults in the new code in
proxy_util.c.
I got the following out of a coredump:
dbx: warning: Some symbolic information might be incorrect.
[EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal SEGV (Segmentation
Fault)
0xfefd42cc: strcasecmp+0x0024: ldub [%o2], %o3
Current function is ap_proxy_determine_connection
1837(strcasecmp(conn-hostname, uri-hostname) != 0) ) ) {
(dbx) where
current thread: [EMAIL PROTECTED]
[1] strcasecmp(0x0, 0x198238, 0xfef183b4, 0xfef183b8, 0xfef183c0,
0xfef183c4), at 0xfefd42cc
=[2] ap_proxy_determine_connection(p = 0x18dd58, r = 0x19bdc8, conf =
0x14be88, worker = 0x14b320, conn = 0x14c1e0, uri = 0x1981f0, url = 0xfea7ba20,
proxyname = (nil), proxyport = 0, server_portstr = 0xfea7b9a8 ,
server_portstr_size = 32), line 1837 in proxy_util.c
[3] proxy_http_handler(r = 0x19bdc8, worker = 0x14b320, conf = 0x14be88, url
= 0x198258 /images/xpop-1.jpg, proxyname = (nil), proxyport = 0), line 1690
in mod_proxy_http.c
[4] proxy_run_scheme_handler(0x19bdc8, 0x14b320, 0x14be88, 0x19d6f0, 0x0,
0x0), at 0xfeefc8e8
[5] proxy_handler(r = 0x19bdc8), line 740 in mod_proxy.c
[6] ap_run_handler(0x19bdc8, 0x14, 0x19cc4d, 0x0, 0x0, 0x0), at 0x5e014
[7] ap_invoke_handler(r = 0x19bdc8), line 373 in config.c
[8] ap_process_async_request(r = 0x19bdc8), line 241 in http_request.c
[9] ap_process_request(r = 0x19bdc8), line 281 in http_request.c
[10] ap_process_http_connection(c = 0x18de80), line 182 in http_core.c
[11] ap_run_process_connection(0x18de80, 0x18dd90, 0x18dd90, 0x2, 0x18de78,
0x191d68), at 0x6a7ac
[12] ap_process_connection(c = 0x18de80, csd = 0x18dd90), line 180 in
connection.c
[13] process_socket(p = 0x18dd58, sock = 0x18dd90, my_child_num = 0,
my_thread_num = 2, bucket_alloc = 0x191d68), line 532 in worker.c
[14] worker_thread(thd = 0xedea0, dummy = 0xdefc0), line 878 in worker.c
[15] dummy_worker(opaque = 0xedea0), line 138 in thread.c
hope this is useful,
Hansjörg
--
IT ServicesUniversity of Innsbruck
CFB4 D6E7 33F4 34C0 18B9 6661 E355 4337 3F8B D9C2
http://purl.org/net/hansjoerg.pehofer/public_key
Re: OT: performance FUD
Jess Holle wrote: So if one uses worker and few processes (i.e. lots of threads per), then Solaris should be fine? That's what people think, but I'd like to see some numbers. I've never put a worker Apache into production because most of our systems depend on PHP or something else which I wouldn't trust 100% in a threaded configuration. Now that I think about it, there is a common situation where people with modest web sites (at the 50,000 ranking in Alexa) have performance problems with Apache... That's the case of people doing downloads of big (1 M files.) Conventional benchmarking, which fetishizes a large and constant number of connections on a LAN doesn't model the situation well (it doesn't model any real-world situation well.) The trouble you have a population of people with really bad connections that take forever to download things... Back when I had dialup, I used to download ISO images, I'd just use a download manager and have my computer running overnight to do it. For one project I work on, we have people uploading files that sometimes are in the ~1 M range, then we do processing on the files that is sometimees extensive. We were worried that some processes were running for 20, 30, 40 minutes, but we discovered that many of our users have horrible connections. The result is that a site with a modest number of hits per day can have 1000 simultaneous connections. With prefork you end up burning a lot more RAM than really seems fair -- although it's not so bad if you can afford to load your machine with 8G.
Re: OT: performance FUD
On Wed, Nov 30, 2005 at 11:01:55AM -0500, Paul A Houle wrote: So if one uses worker and few processes (i.e. lots of threads per), then Solaris should be fine? That's what people think, but I'd like to see some numbers. I've never put a worker Apache into production because most of our systems depend on PHP or something else which I wouldn't trust 100% in a threaded configuration. Is there anything we can do in 2.4/3.0 that will help gain that trust? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: OT: performance FUD
Colm MacCarthaigh wrote: I've never put a worker Apache into production because most of our systems depend on PHP or something else which I wouldn't trust 100% in a threaded configuration. Is there anything we can do in 2.4/3.0 that will help gain that trust? PHP, or it's extensions or whatever they call them, are not thread safe. So until that's fixed, nothing we can do. Probably the same with other stuff. worker wokrs for me, though. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: OT: performance FUD
Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 08:01:41AM -0500, Brian Akins wrote: Colm MacCarthaigh wrote: It's public knowledge that CNN.com runs Apache 2.2, would it cause you a lot of trouble for that to be referenced? As long as it's from public sources (netcraft, HTTP headers, etc) and no one within the orginization is quoted, it shouldn't be a problem, I suppose. I would be hesitant to say yes -- it's my job on-the-line if somebody here doesn't like it :( Well, lets not even come close to risking that. I have been given word that our statements can appear in a press release or testimonial, it just has to be passed through legal here. So what type of statements are we looking for? -- Brian Akins Lead Systems Engineer CNN Internet Technologies
[PATCH] httxt2dbm backport to 2.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://people.apache.org/~rbowen/httxt2dbm_proposed_patch I'd like to copy httx2dbm back into 2.0 from 2.1. This is primarily because I'm tired of telling folks that they can generate RewriteMap dbm files using httxt2dbm if they happen to be running 2.1 or 2.2, which, of course, they aren't. There are no changes from the 2.1 version. It Just Works in its new home. This also fixes the problem that the documented way to generate these hash files doesn't always work for everyone, depending on what particular dbm libraries they happen to have built against. - -- Rich Bowen [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDjdCJXP03+sx4yJMRArILAKChMXvCCyFU+qjx2OxC3bMkdvhv/wCgpjq7 N/+pkYNQ0L4BY9iAWi8H4jQ= =HPoG -END PGP SIGNATURE-
Press release for httpd 2.2 (was Re: OT: performance FUD)
Brian Akins wrote: I have been given word that our statements can appear in a press release or testimonial, it just has to be passed through legal here. So what type of statements are we looking for? Let's bring the Apache Public Relations Committee into this to see what advice they have. We (the Apache HTTP Server Project) would like to put together a press release announcing the release of version 2.2. We can highlight the obvious market penetration numbers and some of the features listed here: http://httpd.apache.org/docs/2.1/new_features_2_2.html But we would like to put particular emphasis on the performance and scalability of httpd. We have two people (Brian Atkins at CNN and Colm MacCárthaigh at HEAnet) who run httpd under extremely high load and are willing to give us some quotes on this topic. Can the PRC give advice on how we should proceed? I am willing to start a draft, if that helps. Is there a template or some advice on format/content? What else should we be doing? Re Brian's question above, I think we want a statement emphasizing performance and scalability. It doesn't need to be extremely precise, spec-wise. Most people reading a press release wouldn't care. We just want to transmit the message that you use apache httpd in a very-high load situation and that it perfoms very well. By the way, are you using 2.0 or 2.1? Joshua.
Re: Press release for httpd 2.2 (was Re: OT: performance FUD)
Joshua Slive wrote: By the way, are you using 2.0 or 2.1? BOth. 2.1 in higher traffic now. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: OT: performance FUD
Colm MacCarthaigh wrote: Is there anything we can do in 2.4/3.0 that will help gain that trust? It's not Apache's fault. It's not even PHP's fault. It's a much bigger problem with the open source libraries that people link into PHP, Perl, Python and the like. The problem is particularly perceived as a PHP problem because (1) PHP is the market leader, and (2) the PHP developers are a lot more responsible than, say, the Python developers, who tell you to go ahead and write threaded apps in Python anyway. I suppose that the PHP developers could set up some system where extensions are marked as being threadsafe or not, and there's a lock on every untrusted module, then do a program of certifying modules as safe, but that's a ~big~ project: race conditions and deadlocks are a bitch to debug, particularly when the problems are in somebody else's code. PHP's market position is as a product that any idiot can download and install, just following the instructions, and get a system with good reliability and performance -- a painful phase of shaking out threading bugs would endanger that perception. The best thing I can see Apache doing is some kind of hybrid model which works like mod_event for static pages, and passes off (some or all) dynamic requests to something like prefork. Dynamic requests would eat more memory than worker, but you don't have the problem of using a heavyweight mod_perl or mod_php process spending two hours blasting bits out of a file to somebody on dialup. A process-based model is always going to be more reliable than a thread-based model. A hand grenade can go off in an server process, a server process can hemorage memory terribly, and nobody gets hurt. The user on the other end just hits 'reload' and goes on hs way.
Re: svn commit: r349979 - /httpd/httpd/branches/2.2.x/STATUS
These might also be useful in patches-to-apply upon release :) == --- httpd/httpd/branches/2.2.x/STATUS (original) +++ httpd/httpd/branches/2.2.x/STATUS Wed Nov 30 08:27:14 2005 @@ -67,8 +67,16 @@ RELEASE SHOWSTOPPERS: -CURRENT VOTES: +PATCHES PROPOSED TO BACKPORT FROM TRUNK: + +* Backport Win32 build fixes for mod_dbd and mod_authn_dbd +http://people.apache.org/~colm/httpd-2.2.0-dbd-win32.patch +http://people.apache.org/~colm/mod_dbd.dsp +http://people.apache.org/~colm/mod_authn_dbd.dsp + colm: +1 +CURRENT VOTES: + RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: WISH LIST: -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: OT: performance FUD
Brian Akins writes: Colm MacCarthaigh wrote: I've never put a worker Apache into production because most of our systems depend on PHP or something else which I wouldn't trust 100% in a threaded configuration. Is there anything we can do in 2.4/3.0 that will help gain that trust? PHP, or it's extensions or whatever they call them, are not thread safe. So until that's fixed, nothing we can do. Probably the same with other stuff. worker wokrs for me, though. -- Brian Akins Lead Systems Engineer CNN Internet Technologies Exactly. I run a website for a former employer which still gets considerable traffic in terms of downloads of large files and runs a medium-to-heavy use forum system based on PHP. Multiple sites built with the LAMP stack (P being PHP in this case, although there is some PERL backend). Right now, in order to keep from bogging a particular server down with latent or slow connections, I have had to impliment a load balanced configuration with multiple servers in a case where one or two could easily suffice if I could trust a multi-threaded model. We have actually discussed this a couple other times on the list. There is (at the very least) a percieved slowness in migration to the 2.0 apache setup and indeed slower to multi-threaded MPMs, even in situations that would absolutely benefit from them. Why? PHP is one of the biggest reasons I have been hearing from colleagues. Has any kind of extensive testing been done against a multi-threaded implementation of a PHP-based testing sled to find out what (if anything) is breaking in a threaded environment? Do we have hard data to offer the PHP community to encourage additional specific work and move towards thread-safe certification of some of the underlying PHP core and modules? - Wayne S. Frazee Any sufficiently developed bug is indistinguishable from a feature.
Re: Various musings about the request URL / URI / whatever
As for the larger issue at hand: the reason req.parsed_uri is not
filled in is because browsers don't send the info in the GET...
Disclaimer: What follows is not an exhaustive, conclusive search by
tracing running code, but rather searching source code and watching
apache behaviour with tools like curl, telneting to the apache port
and using a browser.
Onward...
As mentioned already, req.parsed_uri is a tuple wrapping of a
request_rec.parsed_uri which is an apr_uri_t.
The contents of this struct are touched in many places, but the
primary functions setting this structure are in
srclib/apr-util/uri/apr_uri.c: apr_uri_parse() and
apr_uri_parse_hostinfo(). Doing a search within apache to see where
these functions are called I discovered a number of modules making use
of these functions, but probably not of concern to this issue. The
primary caller is ap_parse_uri() in server/protocol.c.
ap_parse_uri() is called numerous times in server/request.c to deal
with sub-requests; it is also called in modules/http/http_request.c
for internal redirects. The main calling stack which is of concern to
this issue is:
Function Called Function defined in
---
ap_process_http_connection()[modules/http/http_core.c]
= ap_read_request()[server/protocol.c]
= read_request_line() [server/protocol.c]
= ap_parse_uri() [server/protocol.c]
= apr_uri_parse() [srclib/apr-util/uri/apr_uri.c]
ap_parse_uri is called with a request_rec and the uri (as a string);
the string is what read_request_line delivers; this is whatever is
specified with GET during the protocol exchange with the client. If
the uri is full then the whole struct is properly filled in (BTW,
the apr_uri_t is zero'd out with memset in apr_uri_parse).
Observations
I wrote a handler to return, as text/plain, the setting of various req
members of interest to this discussion. I set up apache to run on a
non-default port and required basic auth to access the page so the
full uri will be parsed (theoretically).
When I type the following into my browser (firefox):
http://foo:[EMAIL PROTECTED]:8000/~dpopowich/py/parsed?a=bc=d#here
Here's the output:
req.hostname: localhost
req.unparsed_uri: /~dpopowich/py/parsed?a=bc=d
req.parsed_uri: (None, None, None, None, None, 8000,
'/~dpopowich/py/parsed', 'a=bc=d', None)
req.uri: /~dpopowich/py/parsed
req.args: a=bc=d
It appears only /PATH?QUERY has been passed to the server and I
confirmed this by sniffing the packets. It's interesting that the
port is set and hostname is not...I think this has to do with some
code in the virtual host handling.
Here's the output with a verbose call with curl (same uri as above):
* About to connect() to localhost port 8000
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8000
* Server auth using Basic with user 'foo'
GET /~dpopowich/py/parsed?a=bc=d#here HTTP/1.1
Authorization: Basic Zm9vOmJhcg==
User-Agent: curl/7.15.0 (i486-pc-linux-gnu) libcurl/7.15.0 OpenSSL/0.9.8a
zlib/1.2.3 libidn/0.5.18
Host: localhost:8000
Accept: */*
HTTP/1.1 200 OK
Date: Wed, 30 Nov 2005 15:43:19 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) mod_python/3.2.5b Python/2.3.5
mod_perl/2.0.1 Perl/v5.8.7
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain
req.hostname: localhost
req.unparsed_uri: /~dpopowich/py/parsed?a=bc=d#here
req.parsed_uri: (None, None, None, None, None, 8000,
'/~dpopowich/py/parsed', 'a=bc=d', 'here')
req.uri: /~dpopowich/py/parsed
req.args: a=bc=d
* Closing connection #0
Notice how /PATH?QUERY#FRAGMENT is passed with this client.
Now if I type the following into a telnet session (telnet localhost 8000):
GET http://foo:[EMAIL PROTECTED]:8000/~dpopowich/py/parsed?a=bc=d#here
HTTP/1.1
Authorization: Basic Zm9vOmJhcg==
Host: localhost:8000
Then the output is:
req.hostname: localhost
req.unparsed_uri: http://foo:[EMAIL
PROTECTED]:8000/~dpopowich/py/parsed?a=bc=d#here
req.parsed_uri: ('http', 'foo:[EMAIL PROTECTED]:8000', 'foo', 'bar',
'localhost', 8000, '/~dpopowich/py/parsed', 'a=bc=d', 'here')
req.uri: /~dpopowich/py/parsed
req.args: a=bc=d
Summary
===
o req.hostname is set by the contents of the full URI, or in absence
of a full uri, the value of the Host header (this is what is
actually said in the mod_python docs). As mentioned before, in the
case when HTTP/1.1 AND the full URI are not specified, req.hostname
can be None.
o req.unparsed_uri is set to the uri specified with GET
o req.parsed_uri is the parsing of req.unparsed_uri (although the
port may appear even if it's not in req.unparsed_uri and if it's
not 80). Definitely there's inconsistencies in how apache handles
this struct. A bug? Maybe not, but
Re: OT: performance FUD
Paul A Houle wrote: Jess Holle wrote: So if one uses worker and few processes (i.e. lots of threads per), then Solaris should be fine? That's what people think, but I'd like to see some numbers. I've never put a worker Apache into production because most of our systems depend on PHP or something else which I wouldn't trust 100% in a threaded configuration. That's understandable if you're in that boat. We bundle and support our own Apache builds with our products. Our only dynamic content comes from mod_jk (and thus will come from the proxy AJP module in 2.2), so threading is all well and good. Given that most of our content is dynamic and thus via AJP, Apache performance is never really the issue -- if anything above the application code itself is ever an issue it is the extra hop involved with AJP, but there are clear load-balancing, security, etc, benefits from this architecture. Customers seem to consistently assume that using Apache is giving (substantively) lower overall performance than they'd get with something else, though -- chalk that up to good marketing by Microsoft, Sun, et al. As for the big file issue you note, that would only seem to be a big issue when coupled with slow connections -- which are getting rarer these days -- and much more of an issue with prefork than worker. -- Jess Holle
Re: OT: performance FUD
On 11/30/05, Colm MacCarthaigh [EMAIL PROTECTED] wrote: On Wed, Nov 30, 2005 at 11:01:55AM -0500, Paul A Houle wrote: So if one uses worker and few processes (i.e. lots of threads per), then Solaris should be fine? That's what people think, but I'd like to see some numbers. I've never put a worker Apache into production because most of our systems depend on PHP or something else which I wouldn't trust 100% in a threaded configuration. Is there anything we can do in 2.4/3.0 that will help gain that trust? I recently started a thread with (IMO) a potential solution: Any 'official' Apache FastCGI-like alternative planned? Even if PHP is thread-safe it's still not safe. One (bad) script can kill the entire server. The solution would be to run PHP (and other 'request processors') in a separate process.
Re: [PATCH] httxt2dbm backport to 2.0
On Wed, Nov 30, 2005 at 11:17:13AM -0500, Rich Bowen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://people.apache.org/~rbowen/httxt2dbm_proposed_patch I'd like to copy httx2dbm back into 2.0 from 2.1. This is primarily because I'm tired of telling folks that they can generate RewriteMap dbm files using httxt2dbm if they happen to be running 2.1 or 2.2, which, of course, they aren't. There are no changes from the 2.1 version. It Just Works in its new home. This also fixes the problem that the documented way to generate these hash files doesn't always work for everyone, depending on what particular dbm libraries they happen to have built against. +1. -- justin
Re: OT: performance FUD
On Wednesday 30 November 2005 16:30, Paul A Houle wrote: PHP's market position is as a product that any idiot can download and install, just following the instructions, and get a system with good reliability and performance -- a painful phase of shaking out threading bugs would endanger that perception. That looks a lot like Windows' market position. And I suspect it's no accident: both products have heaped on new 'goodies', all too often at the expense of other considerations. It's IMO also no accident that PHP is moving towards a Windows-like security track record. Which leads me to pose the question: can and should the PHP folks learn anything from how Microsoft are dealing with their tarnished image? And even, how closely should we @apache be watching, lest we ourselves stray from the straight-and-narrow and find ourselves at the wrong end of a bunch of real-life exploits, and/or get tarnished by fallout from elsewhere? -- Nick Kew
Re: Press release for httpd 2.2 (was Re: OT: performance FUD)
On Wed, Nov 30, 2005 at 11:25:06AM -0500, Joshua Slive wrote: Re Brian's question above, I think we want a statement emphasizing performance and scalability. It doesn't need to be extremely precise, spec-wise. Most people reading a press release wouldn't care. We just want to transmit the message that you use apache httpd in a very-high load situation and that it perfoms very well. By the way, are you using 2.0 or 2.1? Here's what we've come up with anyway; ftp.heanet.ie has been using Apache httpd 2.1/2.2 for over 6 months and has handled up to 27,000 concurrent downloads from a single webserver, while delivering terabytes of content per day. Large-file support, graceful-stop and mod_cache have improved our level of service dramatically. That hasn't been approved approved just yet, so please don't use it, but tomorrow when our PR person is back I'll hopefully get it, or something approximating it, approved. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Press release for httpd 2.2 (was Re: OT: performance FUD)
On Wed, Nov 30, 2005 at 05:13:07PM +, Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 11:25:06AM -0500, Joshua Slive wrote: Re Brian's question above, I think we want a statement emphasizing performance and scalability. It doesn't need to be extremely precise, spec-wise. Most people reading a press release wouldn't care. We just want to transmit the message that you use apache httpd in a very-high load situation and that it perfoms very well. By the way, are you using 2.0 or 2.1? Here's what we've come up with anyway; ftp.heanet.ie has been using Apache httpd 2.1/2.2 for over 6 months and has handled up to 27,000 concurrent downloads from a single webserver, while delivering terabytes of content per day. Large-file support, graceful-stop and mod_cache have improved our level of service dramatically. That hasn't been approved approved just yet, so please don't use it, but tomorrow when our PR person is back I'll hopefully get it, or something approximating it, approved. I'll just remind everyone this is a public list and its archived too. =) If you wish to keep things private, we can use [EMAIL PROTECTED] and possibly the PMC list. Yes, there's a difference between including it in a PR and in an informal email, but you never know with press types. -- justin
Re: Press release for httpd 2.2 (was Re: OT: performance FUD)
Let my try to contribute my $.02: Usually, a PR item which tells about company X delivered product Y to customer Z, is signed by both - X and Z. Since most of the organizations don't exist for charity but for business, Z must earn something out of this PR. Sometimes, the fact that Z agreed to be an early adopter and even to put its name on the PR, gives Z a small discount (irrelevant in our case). But the usual case is that only by using the product Y, customer Z succeeded to execute its extraordinary service, and here come some impressive numbers which could not be achieved without Y, and so on. In other words, while the interest of X is clear, the interest of Z is more tricky, and usually Z uses this opportunity to tell the world how great he is. We owe Brian something, not only to pay him for putting the name of CNN here, but also to help him pass his legal staff. So this is, more or less, how I see the PR (not the announcement about 2.2, but specifically the CNN case) (and excuse me for my bad English...): -- Just an example, only to demonstrate what I mean -- After gaining more than 70% of the market (according to market research companies such as NetCraft and Security-Space), the future of the Apache web server looks brigher than ever, and it seems that it has no competitors anymore. But there is still one huge competitor that even Apache can't beat: Previous versions of Apache. It just works, 7 days a week, 24 hours a days, serving millions of requests, without losing even one says John Doe, a webmaster with the moc.com, which is ranked #0 among the hosting providers: After all, even Steve Ballmer said 'Apache is simply better', so why should I upgrade?! If it ain't broken, don't touch it!. But now, with Apache 2.2 coming soon, more and more people argue: We succeeded to hire the best reporters and journalists, but in order to keep our status as the most popular news site, it is not enough to create the best content, but we must find creative ways to deliver the enormous load required by our on-line readers says Brian Akins of CNN. Apache 2.2 allowed us the break even our own records, and reach an amazing number of 77 billion hits, although we started to use it only several days ago. I know no other way to deliver one billion pages per day summarizing Akins. This is the message that the Apache Software Foundation tries to make these days: Apache 1.3 is still the power behind most of the leading websites, but the new release combines the advantages of the old one with new fabulous features and abilities says XXX, a member of the Apache Software Foundation, and as an Open-Source product, it's free, so why not upgrade?!. What are these new features and abilities? XXX tries to shorten his answer, but the new release is so revolutionary, so the list looks infinite: (and here comes an infinite list of the goodies of Apache 2.2). The Apache web server is available for download from httpd.apache.org, free of charge. --- This was only an example, but I hope you got the idea. The only problem with this direction is that some of the newspapers and TVs which should publish it, are direct competitors of CNN, and may prefer to edit it (bad) or even to ignore this PR (bad too). -- Eli Marmor [EMAIL PROTECTED] Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
Re: OT: performance FUD
Nick Kew wrote: That looks a lot like Windows' market position. And I suspect it's no accident: both products have heaped on new 'goodies', all too often at the expense of other considerations. It's IMO also no accident that PHP is moving towards a Windows-like security track record. You'll find skeletons if you go looking in CPAN. Market share is a lot of the reason why people target malware at Windows. If you wrote an email virus for the mac, one mac would infect the other mac and that would be the end of your fun. The real trouble with PHP is that it's sparked a revolution in web server software: code reuse. Before PHP, you couldn't find affordable web hosting for dynamic sites: cgi-bin was so expensive and problematic that mass hosting facilities couldn't afford to host it. Mod_perl would be out of the question. If you wanted to start a weblog or a wiki four years ago, you couldn't find reliable software that would hold up in the real world unless you were willing to put a lot of work in it. Today you can download Drupal, Wordpress or any of a large number of packages. So now there are tens of thousands of site running the same software with predictable URLs that people can mess around with and find bugs in the underlying software. If there were any Perl or Java apps of the same popularity, we'd be seeing the same thing. The difference is you can get a shared web hosting account for $10 / month if you want to run a Wordpress site on PHP, but you really want a dedicated server, more like $200 /month if you want to run mod_perl or Java. If you wanted to match the functionality of PHP, in mod_perl or Java, you'd have to install twenty or so framework modules -- everybody is going to pick a different set of modules, so attackers aren't going to have a consistent profile to hit, but on the other hand, this inconsistency makes it harder to incorporate other people's code into your site.
Re: httpd-2.1.7 Connection-pooling Problem w/ ReverseProxy,
Ahh... no doubt conn-hostname is NULL
Hansjoerg Pehofer wrote:
Jim Jagielski [EMAIL PROTECTED] writes:
Can you try HEAD on httpd-trunk for a fix until something
more robust as far as the connections are implemented...
It gets the backend-connections right, but segfaults in the new code in
proxy_util.c.
I got the following out of a coredump:=20
dbx: warning: Some symbolic information might be incorrect.
[EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal SEGV (Segmentation
Fault)
0xfefd42cc: strcasecmp+0x0024: ldub [%o2], %o3
Current function is ap_proxy_determine_connection
1837(strcasecmp(conn-hostname, uri-hostname) !=3D 0) ) ) {
(dbx) where=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
current thread: [EMAIL PROTECTED]
[1] strcasecmp(0x0, 0x198238, 0xfef183b4, 0xfef183b8, 0xfef183c0, 0xfef18=
3c4), at 0xfefd42cc=20
=3D[2] ap_proxy_determine_connection(p =3D 0x18dd58, r =3D 0x19bdc8, conf =
=3D 0x14be88, worker =3D 0x14b320, conn =3D 0x14c1e0, uri =3D 0x1981f0, url=
=3D 0xfea7ba20, proxyname =3D (nil), proxyport =3D 0, server_portstr =3D 0=
xfea7b9a8 , server_portstr_size =3D 32), line 1837 in proxy_util.c
[3] proxy_http_handler(r =3D 0x19bdc8, worker =3D 0x14b320, conf =3D 0x14=
be88, url =3D 0x198258 /images/xpop-1.jpg, proxyname =3D (nil), proxyport=
=3D 0), line 1690 in mod_proxy_http.c
[4] proxy_run_scheme_handler(0x19bdc8, 0x14b320, 0x14be88, 0x19d6f0, 0x0,=
0x0), at 0xfeefc8e8=20
[5] proxy_handler(r =3D 0x19bdc8), line 740 in mod_proxy.c
[6] ap_run_handler(0x19bdc8, 0x14, 0x19cc4d, 0x0, 0x0, 0x0), at 0x5e014=20
[7] ap_invoke_handler(r =3D 0x19bdc8), line 373 in config.c
[8] ap_process_async_request(r =3D 0x19bdc8), line 241 in http_request.c
[9] ap_process_request(r =3D 0x19bdc8), line 281 in http_request.c
[10] ap_process_http_connection(c =3D 0x18de80), line 182 in http_core.c
[11] ap_run_process_connection(0x18de80, 0x18dd90, 0x18dd90, 0x2, 0x18de7=
8, 0x191d68), at 0x6a7ac=20
[12] ap_process_connection(c =3D 0x18de80, csd =3D 0x18dd90), line 180 in=
connection.c
[13] process_socket(p =3D 0x18dd58, sock =3D 0x18dd90, my_child_num =3D 0=
, my_thread_num =3D 2, bucket_alloc =3D 0x191d68), line 532 in worker.c
[14] worker_thread(thd =3D 0xedea0, dummy =3D 0xdefc0), line 878 in work=
er.c
[15] dummy_worker(opaque =3D 0xedea0), line 138 in thread.c
hope this is useful,
Hansj=F6rg
--=20
IT ServicesUniversity of Innsbruck=20=20=20=20
CFB4 D6E7 33F4 34C0 18B9 6661 E355 4337 3F8B D9C2
http://purl.org/net/hansjoerg.pehofer/public_key
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
Re: Various musings about the request URL / URI / whatever
This is cool stuff, thanks! I'm quessing that perhaps req.parsed_uri makes a lot more sense when Apache is used as a proxy, in which case what follows GET is the full URL. Perhaps we can add something to the docs that says this attribute gets its data from the argument to the HTTP GET method, which is usually just the path in the URL and does not include the protocol, hostname and port. It is only filled in completely when the server is used as a proxy..? (the wording could use improvement) Grisha On Wed, 30 Nov 2005, Daniel J. Popowich wrote: As for the larger issue at hand: the reason req.parsed_uri is not filled in is because browsers don't send the info in the GET... Disclaimer: What follows is not an exhaustive, conclusive search by tracing running code, but rather searching source code and watching apache behaviour with tools like curl, telneting to the apache port and using a browser. Onward... [snip]
Re: OT: performance FUD
On Wednesday 30 November 2005 18:27, Paul A Houle wrote: Nick Kew wrote: That looks a lot like Windows' market position. And I suspect it's no accident: both products have heaped on new 'goodies', all too often at the expense of other considerations. It's IMO also no accident that PHP is moving towards a Windows-like security track record. You'll find skeletons if you go looking in CPAN. Market share is a lot of the reason why people target malware at Windows. That's offtopic and largely untrue. But a counterexample is ontopic: if market share were really the determinant, what webserver would Nimda, Code Red, Code Blue et al have hit? The truth is that Mac, Linux and others have *ample* market share. Even a real minority-system like RiscOS has been targeted. The real trouble with PHP is that it's sparked a revolution in web server software: code reuse. Like CGI.pm, libwww-perl, DBI/DBD et al never did? Erm Before PHP, you couldn't find affordable web hosting for dynamic sites: cgi-bin was so expensive and problematic that mass hosting facilities couldn't afford to host it. Mod_perl would be out of the question. I had no trouble finding cheap CGI hosting before moving to my own server. Actually that's not entirely true: my first host was not competently run. But moving to pair.net in IIRC May '96 got me something that worked well. If there were any Perl or Java apps of the same popularity, we'd be seeing the same thing. There are cultural reasons that are more important. If you post a Perl script that omits perl's taint checking, you'll predictably get flamed for it. So the newbie programmer has to figure out whats going on, and take in some basic principles of security in the process. Of course you can't guarantee that'll work, but it makes a better environment for safety- awareness than PHP. And it's not as if Perl is, in general, something I'd hold up as a role model for good practice, either:-) -- Nick Kew
Re: Various musings about the request URL / URI / whatever
Jorey Bump writes: Gregory (Grisha) Trubetskoy wrote: Perhaps we can add something to the docs that says this attribute gets its data from the argument to the HTTP GET method, which is usually just the path in the URL and does not include the protocol, hostname and port. It is only filled in completely when the server is used as a proxy..? How about: This attribute gets its data from the client-supplied Request-URI. I'd prefer something more explicit (because I'm dense and need 2x4s about the head). I humbly offer the following to the editorial board: unparsed_uri String. The URI without any parsing performed. This is the argument passed to, e.g., the HTTP GET method, and so is completely dependent on the value submitted by the client; you have been warned. Clients typically send a partial uri containing only the path and query with no hostinfo, e.g.: GET /path/to/handler?query=value HTTP/1.1. (Read-Only) parsed_uri Tuple. The value of unparsed_uri broken down into pieces. (scheme, hostinfo, user, password, hostname, port, path, query, fragment). The apache module defines a set of URI_* constants that should be used to access elements of this tuple. Example: fname = req.parsed_uri[apache.URI_PATH] Please note: as stated for unparsed_uri, the value is completely dependent on the uri submitted by the client. Since it is typical for clients to only submit the path and query components the rest of the elements in the tuple will often be None. This is not a bug. (Read-Only) args String. Same as parsed_uri[apache.URI_QUERY] (and CGI QUERY_ARGS). (Read-Only) uri String. The path portion of the URI. Same as parsed_uri[apache.URI_PATH]. (Read-Only) hostname String. Host, as set by a full URI from, e.g., the HTTP GET method, or in absence of a full URI, the value of the Host header. In either case, the value is provided by the client; you have been warned. Note: when set by the Host header (which is typical) this value will differ from parsed_uri[apache.URI_HOSTNAME] (which will be None). See unparsed_uri and parsed_uri. Also, in rare cases (no full URI, no Host header) this value can be None. (Read-Only)
Re: httpd-2.1.7 Connection-pooling Problem w/ ReverseProxy, Loadbalancer
On Nov 29, 2005, at 4:55 PM, Ruediger Pluem wrote: On 11/29/2005 04:12 PM, Jim Jagielski wrote: Can you try HEAD on httpd-trunk for a fix until something more robust as far as the connections are implemented... Just for convenience: http://svn.apache.org/viewcvs?rev=349723view=rev Has someone found out out why we close the connection if r-proxyreq == PROXYREQ_PROXY || r-proxyreq == PROXYREQ_REVERSE? I fear that this is something that has survived from 2.0.x. I am also wondering why mod_proxy_http is storing the connection in the module config. Is this something from 2.0.x days where we had no connection pool or is it a security problem to share one keepalive http backend connections across different client connections and vice versa? Doubtful, since this aspect of the code didn't exist in 2.0. IIRC, it had to do with some aspects of pooling and threads, but it's been awhile since it was folded in. Likely it has to do with AJPs connection pool, but that's a wag. Anyway, I'm likely going to rework that area a bit and move some things around to try to optimize the flow a bit...
Re: Press release for httpd 2.2 (was Re: OT: performance FUD)
On Wed, Nov 30, 2005 at 09:19:25AM -0800, Justin Erenkrantz wrote: I'll just remind everyone this is a public list and its archived too. =) If you wish to keep things private, we can use [EMAIL PROTECTED] and possibly the PMC list. Yes, there's a difference between including it in a PR and in an informal email, but you never know with press types. -- justin Thanks, and just to make the prc aware of one more thing; our release of 2.2.0 will be done ten years to the day (well in as much as a day can be put on it) since Apache 1.0.0. The first ever Apache httpd GA. There may well be some PR in that too :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Press release for httpd 2.2 (was Re: OT: performance FUD)
Colm MacCarthaigh wrote: Thanks, and just to make the prc aware of one more thing; our release of 2.2.0 will be done ten years to the day (well in as much as a day can be put on it) since Apache 1.0.0. The first ever Apache httpd GA. There may well be some PR in that too :) I feel old... :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: Press release for httpd 2.2 (was Re: OT: performance FUD)
On Wed, Nov 30, 2005 at 11:52:38AM -0800, Justin Erenkrantz wrote: --On November 30, 2005 7:39:08 PM + Colm MacCarthaigh [EMAIL PROTECTED] wrote: Thanks, and just to make the prc aware of one more thing; our release of 2.2.0 will be done ten years to the day (well in as much as a day can be put on it) since Apache 1.0.0. The first ever Apache httpd GA. There may well be some PR in that too :) http://mail-archives.apache.org/mod_mbox/httpd-dev/199512.mbox/[EMAIL PROTECTED] Figures that it'd take us 10 years to go from 1.0-2.2. ;-) -- justin It's a great display of our commitment to stability, long-term strategic planning and thinking, enterprise-grade development and trustworthy convervatism. Right? ;-) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Various musings about the request URL / URI / whatever
2005/11/30, Jim Gallacher [EMAIL PROTECTED]:
At this point I think we should leave parsed_uri alone, as it seems todo the correct thing - if not the desired thing. At a minimum we shouldexpand the documentation to warn people of the limitations. I still
think it would be useful to have a tuple similar to parsed_uri, butwhich is fully populated. Or maybe everyone just continues to roll thereown.Regards,Jim
Well, I'm still interested in writing a function that would return a
fully populated parsed_uri-like structure, even in the absence of an
absolute URL in the request path. Call me stubborn, but I still feel
that using a configuration item to tell mod_python the supposed
protocol, server name and listening port is a blatant breach of the DRY
principle. Plus, it would force me to change the configuration file
between my development, test and production platform...Yeah, I'm that lazy :).
So, based on Daniel's excellent posts (thanks, Daniel), here what we have so far :
1) Protocol : http:// or https:// ?
For now the best way to get this is to call
req.add_common_vars() and test whether req.subprocess_env.get('HTTPS')
== 'on'. Using req.is_https() which was proposed in the other thread
Calling APR optional functions provided by modules may be more
elegant, but right now we don't have this method.
2) Server name
Thanks to Daniel's excellent posts, I can see that req.hostname is
the best way to get the server name so far. Unfortunately, it depends
on data sent by the client, but hey, so does the rest of the request
handling ;).
One thing that would be nice is to let Apache sort out this mess and
tell us what is the virtual host name it choose to serve the request.
This is my Holy Grail and I shall seek it from now on.
Ah, while I'm at it, knowing the DocumentRoot of the current VirtualHost would be great, too. But that's another story.
3) Port number
port = req.connection.local_addr[1]
'nuf said.
4) URL or URI or whatever you choose to name the part of the
resource one the physical matters of protocol, server and port are
sorted out
uri = req.uri
Note that this uri can in turn be splitted in something which is lost by the publisher and the req.path_info field, that is IIRC that we can
assert(req.uri.endswith(req.path_info)). I don't know what req.path_info is before the publisher kicks in, though.
Anyway, the length of this thread shows that a bit of clarification is
required. A page named something like What's in an URL ? and
explaining the client-side and server-side view of the various
components of a URL are would be great. I'll try to write a draft this
week-end.
Regards,
Nicolas
Re: Various musings about the request URL / URI / whatever
Ooops from your definition it looks like this holds : req.unparsed_uri = req.uri + req.path_info So we'd better use unparsed_uri to reconstitute the original absolute URL. Before the publisher computes path_info it must be empty, so in this case req.unparsed_uri == req.uri. I'll check this. Regards, Nicolas2005/11/30, Daniel J. Popowich [EMAIL PROTECTED]: Jorey Bump writes: Gregory (Grisha) Trubetskoy wrote: Perhaps we can add something to the docs that says this attribute gets its data from the argument to the HTTP GET method, which is usually just the path in the URL and does not include the protocol, hostname and port. It is only filled in completely when the server is used as a proxy..? How about: This attribute gets its data from the client-supplied Request-URI.I'd prefer something more explicit (because I'm dense and need 2x4sabout the head).I humbly offer the following to the editorial board:unparsed_uriString.The URI without any parsing performed. This is the argument passed to, e.g., the HTTP GET method, and so iscompletely dependent on the value submitted by the client; youhave been warned.Clients typically send a partial uri containingonly the path and query with no hostinfo, e.g.:GET /path/to/handler?query=value HTTP/1.1.(Read-Only)parsed_uriTuple. The value of unparsed_uri broken down into pieces. (scheme,hostinfo, user, password, hostname, port, path, query, fragment). The apache module defines a set of URI_* constants thatshould be used to access elements of this tuple. Example:fname = req.parsed_uri[apache.URI_PATH]Please note: as stated for unparsed_uri, the value is completely dependent on the uri submitted by the client.Since it is typicalfor clients to only submit the path and query components the restof the elements in the tuple will often be None.This is not a bug.(Read-Only)argsString. Same as parsed_uri[apache.URI_QUERY] (and CGIQUERY_ARGS). (Read-Only)uriString.The path portion of the URI. Same asparsed_uri[apache.URI_PATH ].(Read-Only)hostnameString. Host, as set by a full URI from, e.g., the HTTP GETmethod, or in absence of a full URI, the value of the Host header.In either case, the value is provided by the client; you have been warned.Note: when set by the Host header (which is typical) thisvalue will differ from parsed_uri[apache.URI_HOSTNAME] (which willbe None).See unparsed_uri and parsed_uri.Also, in rare cases (no full URI, no Host header) this value can be None.(Read-Only)
Re: Press release for httpd 2.2 (was Re: OT: performance FUD)
On Nov 30, 2005, at 11:56 AM, Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 11:52:38AM -0800, Justin Erenkrantz wrote: --On November 30, 2005 7:39:08 PM + Colm MacCarthaigh [EMAIL PROTECTED] wrote: Thanks, and just to make the prc aware of one more thing; our release of 2.2.0 will be done ten years to the day (well in as much as a day can be put on it) since Apache 1.0.0. The first ever Apache httpd GA. There may well be some PR in that too :) http://mail-archives.apache.org/mod_mbox/httpd-dev/199512.mbox/% [EMAIL PROTECTED] Figures that it'd take us 10 years to go from 1.0-2.2. ;-) -- justin It's a great display of our commitment to stability, long-term strategic planning and thinking, enterprise-grade development and trustworthy convervatism. Right? ;-) Yes and we should milk that for all it's worth. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Press release for httpd 2.2 (was Re: OT: performance FUD)
On Wednesday 30 November 2005 20:09, Sander Temme wrote: It's a great display of our commitment to stability, long-term strategic planning and thinking, enterprise-grade development and trustworthy convervatism. Right? ;-) Yes and we should milk that for all it's worth. There was talk of an Apachecon-Stuttgart release date. The extra six months demonstrates our committment to quality and stability ... ... or could look like a Microsoft release schedule. -- Nick Kew
Re: Various musings about the request URL / URI / whatever
Daniel J. Popowich wrote: Jorey Bump writes: Gregory (Grisha) Trubetskoy wrote: Perhaps we can add something to the docs that says this attribute gets its data from the argument to the HTTP GET method, which is usually just the path in the URL and does not include the protocol, hostname and port. It is only filled in completely when the server is used as a proxy..? How about: This attribute gets its data from the client-supplied Request-URI. I'd prefer something more explicit (because I'm dense and need 2x4s about the head). I humbly offer the following to the editorial board: unparsed_uri String. The URI without any parsing performed. This is the argument passed to, e.g., the HTTP GET method, and so is completely dependent on the value submitted by the client; you have been warned. Clients typically send a partial uri containing only the path and query with no hostinfo, e.g.: GET /path/to/handler?query=value HTTP/1.1. (Read-Only) parsed_uri Tuple. The value of unparsed_uri broken down into pieces. (scheme, hostinfo, user, password, hostname, port, path, query, fragment). The apache module defines a set of URI_* constants that should be used to access elements of this tuple. Example: fname = req.parsed_uri[apache.URI_PATH] Please note: as stated for unparsed_uri, the value is completely dependent on the uri submitted by the client. Since it is typical for clients to only submit the path and query components the rest of the elements in the tuple will often be None. This is not a bug. (Read-Only) args String. Same as parsed_uri[apache.URI_QUERY] (and CGI QUERY_ARGS). (Read-Only) uri String. The path portion of the URI. Same as parsed_uri[apache.URI_PATH]. (Read-Only) hostname String. Host, as set by a full URI from, e.g., the HTTP GET method, or in absence of a full URI, the value of the Host header. In either case, the value is provided by the client; you have been warned. Note: when set by the Host header (which is typical) this value will differ from parsed_uri[apache.URI_HOSTNAME] (which will be None). See unparsed_uri and parsed_uri. Also, in rare cases (no full URI, no Host header) this value can be None. (Read-Only) Everything you've stated above is true except when it's not. :) Using an internal_redirect messes with some of these attributes but not others. Those that change get their new values from the new_uri used in the redirect. Unchanged values are from the initial request. req.internal_redirect(new_uri) the_requestunchanged unparsed_uri new parsed_uri new args new uriunchanged hostname unchanged Regards, Jim
Re: Various musings about the request URL / URI / whatever
Jim Gallacher wrote: Using an internal_redirect messes with some of these attributes but not others. Those that change get their new values from the new_uri used in the redirect. Unchanged values are from the initial request. req.internal_redirect(new_uri) the_requestunchanged unparsed_uri new parsed_uri new args new uriunchanged ^ urinew (oops - wee typo there) hostname unchanged Regards, Jim
Re: [vote] 2.2.0 tarballs
Joe Orton wrote: It's pretty silly for anybody to suddenly wake up and declare some random bug as a showstopper for 2.2. Nobody has cared enough about the problem to fix it in the six months and four(?) 2.1.x alpha/beta releases that mod_dbd has been in the tree. So it clearly isn't really very critical to anybody, and isn't showstopper material. Exactly. I've stopped testing httpd-2.1.x because there was nobody interested in testing apr-iconv 1.1.1, a prereq to httpd-2.1/2.2. Without any community interest, httpd on Win32 is clearly my toy, not a project port. I have no intention of rolling any 2.2, voting on any 2.2, until httpd will either correctly build on unix against apr 1.2, or emit a sensible failure. REGARDLESS of whether apr 1.0/1.1 is installed in the system path. I'm voting -1 until the issue of packaging apr/apr-util/apr-iconv in the httpd tarball is resolved. The last I heard, there were folks voting AGAINST this, yet I saw these trees in httpd-2.1.10 tarball. Why? And the suggestion to have an httpd-2.x.x-bundle.tar.gz was raised, that we include apr/apr-util/kitchen sink. That never saw a resolution, with several of those against apr being rolled into httpd, also being against this proposal. No legitimate counterproposals were offered. There's no way that this list has agreement/concluded vote on if srclib/ should include apr/apr-util/expat, and when it's present ./configure is doing the wrong things. So we perpetuate (nay - it's made worse) the 2.0 just to push this out the door. Roy's point of how f'ed up many fink distributions are is rather funny, it's the reason my Mac isn't building httpd-2.2 from svn, and the reason I'm building new toolchains on Win32. The last thing I want is for httpd to be as much of a mess as most of the packages out there, today :-) Bill
Re: [vote] 2.2.0 tarballs
Jim Jagielski wrote: Joe Orton wrote: Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. Now *that's* a statement for the Release Notes :) Absolutely, add to this list AIX, OS2, Netware, BeOS, HPUX and many others. Not to mention OS/390, BS2000 and several others I don't think we can build on since 1.3. Perhaps the Apache HTTP Server for Linux 2.6/Solaris 10/BSD 4 would be a more appropriate name for this project, based on the current community participation, as long as we are going for Truth in Advertising. Of course there are maintainers for each of those 'others', but since active development has become nothing but Linux/Solaris/BSD we should specify supported platforms, not bother to list the dozens of platforms that are not as closely maintained. Bill
Re: [vote] 2.2.0 tarballs
Joost de Heer wrote: Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. And how many people compile the thing on Windows anyway, except the msi builder? My guess is that I need about 2 hands to count them Au contrare, I get feedback personally from about 25 people a year, that ping me personally about something, and about 5 folks who maintain their own bin distributions that include 'other things'. I count 10 people on this list alone who build for win32 when they have a reason to. And there are several posts a month to users@ or entries in the bugzilla from folks having problems. The question isn't how many you know are building, the question is how many we don't know. Success == silence :) Bill
Re: Various musings about the request URL / URI / whatever
Jim Gallacher writes: Jim Gallacher wrote: Using an internal_redirect messes with some of these attributes but not others. Those that change get their new values from the new_uri used in the redirect. Unchanged values are from the initial request. req.internal_redirect(new_uri) the_requestunchanged unparsed_uri new parsed_uri new args new uriunchanged ^ urinew (oops - wee typo there) hostname unchanged Jim, Really, I don't mean to be obtuse, but I'm not groking your point. Are you clarifying that for internal redirects the *source* for these attributes is different than what I was saying in my documentation or is there something more subtle than that? Are you suggesting a change or is this academic? Slow, but sure, Daniel Popowich --- http://home.comcast.net/~d.popowich/mpservlets/
Re: svn commit: r349752 - in /httpd/httpd/trunk/modules/database: mod_dbd.c mod_dbd.h
Nick Kew wrote: On Tuesday 29 November 2005 16:37, [EMAIL PROTECTED] wrote: -AP_DECLARE(void) ap_dbd_prepare(server_rec *s, const char *query, +DBD_DECLARE(void) ap_dbd_prepare(server_rec *s, const char *query, const char *label) OK, other modules do this. Yet the #defines for DBD_DECLARE et al are identical to AP_DECLARE, aren't they? What is supposed to be the purpose of namespacing different modules? Search the archives for DAV_DECLARE, I had a lengthy explanation.
Re: Various musings about the request URL / URI / whatever
Nicolas Lehuen wrote: 2005/11/30, Jim Gallacher [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: At this point I think we should leave parsed_uri alone, as it seems to do the correct thing - if not the desired thing. At a minimum we should expand the documentation to warn people of the limitations. I still think it would be useful to have a tuple similar to parsed_uri, but which is fully populated. Or maybe everyone just continues to roll there own. Regards, Jim Well, I'm still interested in writing a function that would return a fully populated parsed_uri-like structure, even in the absence of an absolute URL in the request path. Call me stubborn, but I still feel that using a configuration item to tell mod_python the supposed protocol, server name and listening port is a blatant breach of the DRY principle. Plus, it would force me to change the configuration file between my development, test and production platform...Yeah, I'm that lazy :). That's not lazy, it's smart. Test and production should be as similar as is possible. Ah, while I'm at it, knowing the DocumentRoot of the current VirtualHost would be great, too. But that's another story. I don't know that story. Is there a problem with req.document_root()? 4) URL or URI or whatever you choose to name the part of the resource one the physical matters of protocol, server and port are sorted out uri = req.uri Note that this uri can in turn be splitted in something which is lost by the publisher and the req.path_info field, that is IIRC that we can assert(req.uri.endswith(req.path_info)). I don't know what req.path_info is before the publisher kicks in, though. I'm not sure I understand what is being lost since publisher does not modify req.uri. Something that I've found useful but which seems to be missing is the idea of a base_uri, where uri = base_uri + path_info Or maybe the base_uri part is what you mean when you say something is lost? Anyway, the length of this thread shows that a bit of clarification is required. A page named something like What's in an URL ? and explaining the client-side and server-side view of the various components of a URL are would be great. I'll try to write a draft this week-end. Excellent. The corollary of this discussion is putting the parsed_uri back together again. Is there any support for exposing apr_uri_unparse()? Jim
Re: OT: performance FUD
Justin Erenkrantz wrote: --On November 29, 2005 3:40:11 PM -0500 Paul A Houle [EMAIL PROTECTED] wrote: * prefork and worker seem to be about equally fast on linux? * MacOS X? fork() is *painfully* slow on the darwin kernel, I haven't tested but can't imagine that threading isn't a huge win here.
Re: Various musings about the request URL / URI / whatever
Daniel J. Popowich wrote: Jorey Bump writes: Gregory (Grisha) Trubetskoy wrote: Perhaps we can add something to the docs that says this attribute gets its data from the argument to the HTTP GET method, which is usually just the path in the URL and does not include the protocol, hostname and port. It is only filled in completely when the server is used as a proxy..? How about: This attribute gets its data from the client-supplied Request-URI. I'd prefer something more explicit (because I'm dense and need 2x4s about the head). I humbly offer the following to the editorial board: unparsed_uri String. The URI without any parsing performed. This is the argument passed to, e.g., the HTTP GET method, and so is completely dependent on the value submitted by the client; you have been warned. Clients typically send a partial uri containing only the path and query with no hostinfo, e.g.: GET /path/to/handler?query=value HTTP/1.1. (Read-Only) parsed_uri Tuple. The value of unparsed_uri broken down into pieces. (scheme, hostinfo, user, password, hostname, port, path, query, fragment). The apache module defines a set of URI_* constants that should be used to access elements of this tuple. Example: fname = req.parsed_uri[apache.URI_PATH] Please note: as stated for unparsed_uri, the value is completely dependent on the uri submitted by the client. Since it is typical for clients to only submit the path and query components the rest of the elements in the tuple will often be None. This is not a bug. (Read-Only) args String. Same as parsed_uri[apache.URI_QUERY] (and CGI QUERY_ARGS). (Read-Only) uri String. The path portion of the URI. Same as parsed_uri[apache.URI_PATH]. (Read-Only) hostname String. Host, as set by a full URI from, e.g., the HTTP GET method, or in absence of a full URI, the value of the Host header. In either case, the value is provided by the client; you have been warned. Note: when set by the Host header (which is typical) this value will differ from parsed_uri[apache.URI_HOSTNAME] (which will be None). See unparsed_uri and parsed_uri. Also, in rare cases (no full URI, no Host header) this value can be None. (Read-Only) +1 on your definitions, but I have another issue, related to this thread... This discussion leads me to believe that req.hostname, in its current implementation, is hopelessly ambiguous. It is already doing what we've concluded in this thread to be a Bad Thing(TM) by automagically interposing two completely unrelated values simply to avoid returning None. Can anyone conceive of a use case where it would be alright to rely on this value, even when it's been arbitrarily populated by a client-supplied absoluteURI (via a proxy, for example)? What would a developer expect to be contained in this value? For myself, I would prefer it to be a high-level interface to req.headers_in['Host'], in which case, None would be somewhat meaningful. Even better, deprecate req.hostname in 3.2, where we can add req.host to contain the value in req.headers_in['Host']. Then drop req.hostname in 3.3 completely. This will give developers some time to adapt. Finally, I'm getting the impression that most developers are looking for a portable way to get the ServerName, as defined in the Apache configuration. This may currently be achieved in a variety of ways, including: servername = req.server.server_hostname or: req.add_common_vars() servername = req.subprocess_env['SERVER_NAME'] So, getting back to Nicolas' original post, and reaffirming Grisha's point that req.hostname isn't appropriate in his script, maybe req.server.server_hostname will work, in that it allows one to construct an URL that gets the user back to the site, even if it doesn't exactly match the URL displayed in the browser during the original request. Does the fact that this is a difficult discovery warrant the addition of another high-level attribute, req.servername?
Re: OT: performance FUD
Brian Akins wrote: Colm MacCarthaigh wrote: I've never put a worker Apache into production because most of our systems depend on PHP or something else which I wouldn't trust 100% in a threaded configuration. Is there anything we can do in 2.4/3.0 that will help gain that trust? PHP, or it's extensions or whatever they call them, are not thread safe. So until that's fixed, nothing we can do. Probably the same with other stuff. I don't suppose we should respond to the fud that PHP is 20th century technology that isn't compatible with 21st century high-availablity operating systems? Seems like it would be in poor taste :) Someone once suggested a list of the 'minimum library versions' for thread safety and reentrant support (note the 2nd may be required as the async httpd server evolves.) Essentially without that knowledge, although PHP is mostly thread safe, the extentions are unknowns. Bill
Re: Press release for httpd 2.2 (was Re: OT: performance FUD)
Justin Erenkrantz wrote: --On November 30, 2005 7:39:08 PM + Colm MacCarthaigh [EMAIL PROTECTED] wrote: Figures that it'd take us 10 years to go from 1.0-2.2. ;-) -- justin Good point, I propose we call this coming release 3.0 :)
Re: [vote] 2.2.0 tarballs
Once 2.2 is released we'll be working to use it -- and distribute it with our products -- on Windows, Solaris, and AIX. I throw in patches relevant to these platforms when possible, but I don't have the time or interest in native (non-Java) code anymore to help out more. -- Jess Holle William A. Rowe, Jr. wrote: Jim Jagielski wrote: Joe Orton wrote: Win32 is not special. It's a second-class citizen if anything because it gets so little developer attention. Now *that's* a statement for the Release Notes :) Absolutely, add to this list AIX, OS2, Netware, BeOS, HPUX and many others. Not to mention OS/390, BS2000 and several others I don't think we can build on since 1.3. Perhaps the Apache HTTP Server for Linux 2.6/Solaris 10/BSD 4 would be a more appropriate name for this project, based on the current community participation, as long as we are going for Truth in Advertising. Of course there are maintainers for each of those 'others', but since active development has become nothing but Linux/Solaris/BSD we should specify supported platforms, not bother to list the dozens of platforms that are not as closely maintained. Bill
Re: Press release for httpd 2.2 (was Re: OT: performance FUD)
William A. Rowe, Jr. wrote: Good point, I propose we call this coming release 3.0 :) No It should be Apache HTTP X (ten). All the other cool things are at 10 (or close). Mac OS, Solaris, Suse, Redhat, Mandrake -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: Various musings about the request URL / URI / whatever
On Wed, 30 Nov 2005, Jorey Bump wrote: Can anyone conceive of a use case where it would be alright to rely on this value, even when it's been arbitrarily populated by a client-supplied absoluteURI (via a proxy, for example)? What would a developer expect to be contained in this value? For myself, I would prefer it to be a high-level interface to req.headers_in['Host'], in which case, None would be somewhat meaningful. req.hostname is the value of hostname in httpd's req_rec structure. Even better, deprecate req.hostname well... this is the wrong list for this - req.hostname just reflects the value of req_rec-hostname, you'd have to suggest the deprecation to dev@httpd.apache.org :) in 3.2, where we can add req.host to contain the value in req.headers_in['Host']. The only value I see in this is saving 14 keystrokes. Finally, I'm getting the impression that most developers are looking for a portable way to get the ServerName Keep in mind that ServerName doesn't always exist, but req.server.server_hostname is the right place to get it. req.add_common_vars() servername = req.subprocess_env['SERVER_NAME'] That's a waste of CPU cycles, since add_common_vars() copies it from req.server.server_hostname (most likely, haven't check for sure) So, getting back to Nicolas' original post, and reaffirming Grisha's point that req.hostname isn't appropriate in his script, maybe req.server.server_hostname will work, in that it allows one to construct an URL that gets the user back to the site, even if it doesn't exactly match the URL displayed in the browser during the original request. Good point... I won't comment on this since I believe that URL-deduction is the wrong approach to begin with ;-) Does the fact that this is a difficult discovery warrant the addition of another high-level attribute, req.servername? Why introduce redundancy if there already is req.server.server_hostname? Grisha
Re: [vote] 2.2.0 tarballs
On Wed, Nov 30, 2005 at 09:22:58PM +, Nick Kew wrote: Can someone clarify: what happens *by default* if APR 1.0/1.1 is found on a target machine? If it tries to build against that, I'd support a -1. If it does something sensible - which could be emitting an error message and refusing to build - I'd not worry. It refuses to configure, you need to go build apr/apu 1.2 somewhere and reconfig with the --with-apr(-util) options. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Various musings about the request URL / URI / whatever
On Wed, 30 Nov 2005, Jorey Bump wrote: Nicolas Lehuen wrote: 2) Server name Thanks to Daniel's excellent posts, I can see that req.hostname is the best way to get the server name so far. Unfortunately, it depends on data sent by the client, but hey, so does the rest of the request handling ;). req.server.server_hostname is unambiguous, and I can't think of a real-world situation in which it would be None. It matches the ServerName in your Apache configuration, so won't this be a reliable value to use when reconstructing an URL? To add just a tad more confusion here - don't forget ServerAlias, which is also a perfectly valid value for the deduced URL. ;-) Grisha
Re: httpd-2.1.7 Connection-pooling Problem w/ ReverseProxy, Loadbalancer
On 11/30/2005 08:38 PM, Jim Jagielski wrote: On Nov 29, 2005, at 4:55 PM, Ruediger Pluem wrote: [..cut..] Has someone found out out why we close the connection if r-proxyreq == PROXYREQ_PROXY || r-proxyreq == PROXYREQ_REVERSE? I fear that this is something that has survived from 2.0.x. I am also wondering why mod_proxy_http is storing the connection in the module config. Is this something from 2.0.x days where we had no connection pool or is it a security problem to share one keepalive http backend connections across different client connections and vice versa? Doubtful, since this aspect of the code didn't exist in 2.0. IIRC, it had to do with some aspects of pooling and threads, but it's been awhile since it was folded in. Likely it has to do with AJPs connection pool, but that's a wag. Ok, regarding the PROXYREQ_REVERSE issue you are right. I had a look at the 2.0.x code meanwhile (sorry been too lazy for that before) and found no signs for this. Regarding the storage of the backend connection in the module config I found very similar code pieces in the old 2.0.x sources so I think it is an heritage from 2.0.x. I believe the clearer approach would be to fetch the connection from the connection pool each time and do not use this module config method any longer. This would also resolve the problem of Hans-Joerg which you fixed with your recent patches as we would get the correct connection then anyway. From a first quick view the whole infrastructure for doing this seems to be prepared pretty well already. Anyway, I'm likely going to rework that area a bit and move some things around to try to optimize the flow a bit... I also hope to have some time on the weekend to make some thoughts. As soon as they are made I'll let you and everyone know :-). Regards Rüdiger
Re: [vote] 2.2.0 tarballs
Nick Kew wrote: I diskile bundling APR, and dislike even more bundling third-party libs like expat and pcre. But I thought I/we had just lost that argument with louder voices. We lost the argument over pcre; our requirement is apparently just a little to particular to have the user obtain any distro of pcre, since it would not work out of the box. Not true, apparently, of expat, zlib, openssl, openldap, apr or apr-util.
Re: Various musings about the request URL / URI / whatever
Gregory (Grisha) Trubetskoy wrote: On Wed, 30 Nov 2005, Jorey Bump wrote: req.add_common_vars() servername = req.subprocess_env['SERVER_NAME'] That's a waste of CPU cycles, since add_common_vars() copies it from req.server.server_hostname (most likely, haven't check for sure) It may be wasteful for fetching a single environment value, but add_common_vars() gathers all sorts of disparate information into one interface, subprocess_env, for those with a CGI bent.
Re: [vote] 2.2.0 tarballs
On Wed, Nov 30, 2005 at 02:43:24PM -0600, William A. Rowe, Jr. wrote: Exactly. I've stopped testing httpd-2.1.x because there was nobody interested in testing apr-iconv 1.1.1, a prereq to httpd-2.1/2.2. Without any community interest, httpd on Win32 is clearly my toy, not a project port. It was hardly nobody, I may be shoddily inexperienced with the win32 port, but I did go to the trouble of testing apr-iconv on win32 and have been regularly building 2.1/2.2 on win32 to make sure it builds/works for me. And we've heard from others doing the same. dbd slipped through because it wasn't included in the build environment, and hence did not affect the process. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Various musings about the request URL / URI / whatever
2005/11/30, Jim Gallacher [EMAIL PROTECTED]: [snip] Nicolas Lehuen wrote: Ah, while I'm at it, knowing the DocumentRoot of the current VirtualHost would be great, too. But that's another story.I don't know that story. Is there a problem with req.document_root()? Well, I think I'm doing a bad thing, and I have to stop doing it. I'm using mod_vhost_alias, which is a way to implement mass virtual hosting. It's kind of neat, since you get one document root per virtual host, all document roots are subdirs of a common parent directory, without the hassle of using mod_rewrite. However, it seems a bit unfinished on the edges since req.document_root() returns the common parent directory instead of the true, per-virtual host document root. Also, I don't know if using mod_rewrite to implement mass virtual hosting can change the document root accordingly. So the only way to know my document root is to compute it from the common parent directory and the virtual host name, and bam, we're back on our track of how do I get the current virtual host name ?. 4) URL or URI or whatever you choose to name the part of the resource one the physical matters of protocol, server and port are sorted out uri = req.uri Note that this uri can in turn be splitted in something which is lost by the publisher and the req.path_info field, that is IIRC that we can assert(req.uri.endswith (req.path_info)). I don't know what req.path_info is before the publisher kicks in, though.I'm not sure I understand what is being lost since publisher does notmodify req.uri. Something that I've found useful but which seems to be missing is the idea of a base_uri, whereuri = base_uri + path_infoOr maybe the base_uri part is what you mean when you say something is lost? Using the enclosed file, which is both a test handler and a page that can be published, I got those results : 1) Using test.py as a handler URI --- req.unparsed_uri: '/test.handler/subpath#toto' req.parsed_uri: (None, None, None, None, None, None, '/test.handler/subpath', None, 'toto') req.uri: '/test.handler/subpath' req.path_info: '/subpath' req.subprocess_env.get(SCRIPT_NAME): '/test.handler' req.subprocess_env.get(PATH_INFO): '/subpath' req.subprocess_env.get(SCRIPT_URL): None req.subprocess_env.get(SCRIPT_URI): None 2) Using the publisher handler to publish test.py URI --- req.unparsed_uri: '/test.py/subpath#toto' req.parsed_uri: (None, None, None, None, None, None, '/test.py/subpath', None, 'toto') req.uri: '/test.py/subpath' req.path_info: '/subpath' req.subprocess_env.get(SCRIPT_NAME): '/test.py' req.subprocess_env.get(PATH_INFO): '/subpath' req.subprocess_env.get(SCRIPT_URL): None req.subprocess_env.get(SCRIPT_URI): None I must confess I'm completely at a loss here... a) Handlers and published modules seem to behave the same way, so the computation of path_info must come from above, i.e. either from mod_python or from Apache. b) We've gotreq.uri == req.subprocess_env.get(SCRIPT_NAME) + req.subprocess_env.get(PATH_INFO). Cool, but who does the split ? I'm guessing that it's Apache who does it thanks to the AddHandler directives ; it knows that the .py extension must be served by mod_python, hence it deduces that /test.py must be the script name and /subpath some path info to provide the script with. c) We don't have a req.base_uri (to follow Jim's naming suggestion) or req.script_name that would be equivalent to req.subprocess_env.get(SCRIPT_NAME), but we have a req.path_info... Why is this missing ? I'm beginning to think that all this feels highly un-pythonic. There are a lot more than one way to get some data (the host name is a good example). You get to use req.foobar or req.subprocess_env['FOOBAR'] or req.server.foobar (and feel happy if there is only one FOOBAR which gives you the data you need). subprocess_env is a very ugly name which doesn't seem to be related to mod_python at all (I'm using the multi-threaded MPM and I don't have subprocesses). For some data, there is no way to get it (where is the current virtual host name, as determined by Apache ?). One thing I'll try to do is to write a kind of Rosetta Stone with all the data you can find in a URL, how to get it from the request/connection/server object, how to get it from subprocess_env (i.e. how you would get it in a CGI), and what is missing or duplicated. This way we'll be able to decide if we should deprecate some paths to those data and remove them in a later release (3.3 or 3.4). The end result would be a series of statements like If you want to get the virtual host name, then use XYZ, don't use ABC which is deprecated. Be aware though that it's not 100% efficient, blah blah. Regards, Nicolas Anyway, the length of this thread shows that a bit of clarification is required. A page named something like What's in an URL ? and explaining the client-side and server-side view of the various components of a URL are would be great. I'll try to write a draft this week-end.Excellent.The corollary of
Re: [vote] 2.2.0 tarballs
Build the php5apache2.dll ( php 5.1.1 apache2handler) with 2.2.0 on Win32. No issues. Steffen
Re: Various musings about the request URL / URI / whatever
Daniel J. Popowich wrote:
Jim Gallacher writes:
Jim Gallacher wrote:
Using an internal_redirect messes with some of these attributes but not
others. Those that change get their new values from the new_uri used in
the redirect. Unchanged values are from the initial request.
req.internal_redirect(new_uri)
the_requestunchanged
unparsed_uri new
parsed_uri new
args new
uriunchanged
^
urinew (oops - wee typo there)
hostname unchanged
Jim,
Really, I don't mean to be obtuse, but I'm not groking your point.
Are you clarifying that for internal redirects the *source* for these
attributes is different than what I was saying in my documentation
Exactly. The documentation needs to account for the different behaviour
after an internal_redirect. I'll let the code talk for me as I can't
come up with adequate text. Assume you are using publisher with the
following code.
Client request:
http://www.example.com/mod_python/parsed_uri/mptest.py?blah=de-blah
mptest.py
-
def index(req):
req.content_type = 'text/plain'
req.write('-\nindex\n-\n')
stuff(req)
# I'm sorry about the look of the next statement -
# thunderbird line wrapping issues
req.internal_redirect(http://ABCDE.example.org:666;
/mod_python/parsed_uri/mptest/redirect
?inquisition=spanish#foo)
def redirect(req):
req.write('\n\n\nredirect\n\n')
stuff(req)
def stuff(req):
req.write('req.the_request: %s\n' % req.the_request)
req.write('req.uri: %s\n' % req.uri)
req.write('req.unparsed_uri: %s\n' % str(req.unparsed_uri))
req.write('req.parsed_uri: %s\n' % str(req.parsed_uri))
req.write('req.hostname: %s\n' % req.hostname)
req.write('req.args: %s\n' % req.args)
Output:
===
-
index
-
req.the_request: GET /mod_python/parsed_uri/mptest?blah=de-blah HTTP/1.1
req.uri: /mod_python/parsed_uri/mptest.py
req.unparsed_uri: /mod_python/parsed_uri/mptest
req.parsed_uri: (None, None, None, None, None, None,
'/mod_python/parsed_uri/mptest', 'blah=de-blah', None)
req.hostname: www.example.org
req.args: blah=de-blah
redirect
req.the_request: GET /mod_python/parsed_uri/mptest HTTP/1.1
req.uri: /mod_python/parsed_uri/mptest.py/redirect
req.unparsed_uri:
http://ABCDE.example.org:666/mod_python/parsed_uri/mptest/redirect?inquisition=spanish#foo
req.parsed_uri: ('http', 'ABCDE.example.org:666', None, None,
'ABCDE.example.org', 666, '/mod_python/parsed_uri/mptest/redirect',
'inquisition=spanish', 'foo')
req.hostname: www.example.org
req.args: inquisition=spanish
Jim
Re: svn commit: r349582 - /httpd/httpd/tags/2.2.0/
Roy T.Fielding wrote: This is exactly what I said I would do in the [vote] thread for 2.1.10. No, it isn't -- you said that it was a vote to release 2.1.10. I assumed that meant you were going to bump the version number in CVS. There were several people who said they were +1 on 2.1.10 and NOT 2.2.0, and our voting guidelines have never allowed a release vote to take place before the release was even prepared. Well, there were enough votes that 2.1.10 was GA quality, and 2.1.x will never be GA, I believe most of the community understood that as 'graduating' 2.1 to 2.2 (with the appropriate patches and vote on the final 2.2.0 package). The transition to 2.2.0 couldn't happen without a vote, and I believe that Paul called for that vote close-to-properly. Those of us voting against 2.2.0 from his 2.1.10 tag were, I believe, outvoted, and new version/releases can't be vetoed. But if 2.2.0 fails to pass muster, note that the next package will be 2.2.1, with 2.2.0 unreleased (perhaps a good thing for folks who avoid .zeros.) Bill
Fwd: Various musings about the request URL / URI / whatever
2005/11/30, Jorey Bump [EMAIL PROTECTED]: Finally, I'm getting the impression that most developers are looking fora portable way to get the ServerName, as defined in the Apacheconfiguration. This may currently be achieved in a variety of ways,including: servername = req.server.server_hostnameor: req.add_common_vars() servername = req.subprocess_env['SERVER_NAME']So, getting back to Nicolas' original post, and reaffirming Grisha's point that req.hostname isn't appropriate in his script, maybereq.server.server_hostname will work, in that it allows one to constructan URL that gets the user back to the site, even if it doesn'texactly match the URL displayed in the browser during the original request.Does the fact that this is a difficult discovery warrant the addition ofanother high-level attribute, req.servername? The problem, as I've mentioned in my previous post, is that ServerName does not mean anything in mass virtual hosting environments, at least in my current settings (I don't exclude the fact that I've done something wrong). Using the test script provided in my previous post, the ServerName value is consistently wrong, always being equal to 'localhost' even if it's not the virtual host that was requested and serviced. Anyway, like I've wrote, maybe mass virtual hosting is a stupid idea, all the more since my production server only has 30 or so virtual hosts, so I could manage them all by traditional VirtualHost directives... At least with true VirtualHost directives it's easy to set and use the ServerName value. Regards, Nicolas
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 02:43:24PM -0600, William A. Rowe, Jr. wrote: It was hardly nobody, I may be shoddily inexperienced with the win32 port, but I did go to the trouble of testing apr-iconv on win32 and have been regularly building 2.1/2.2 on win32 to make sure it builds/works for me. And we've heard from others doing the same. It was close to nobody, the only reason it is released is that yourself, and Garrett both stepped up. But I posted far more pings than I received in testers, and it took two months :) Thank you two for the review, no slight intended. Bill
Re: Various musings about the request URL / URI / whatever
2005/11/30, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]: On Wed, 30 Nov 2005, Jorey Bump wrote: Nicolas Lehuen wrote: 2) Server name Thanks to Daniel's excellent posts, I can see that req.hostname is the best way to get the server name so far. Unfortunately, it depends on data sent by the client, but hey, so does the rest of the request handling ;). req.server.server_hostname is unambiguous, and I can't think of a real-world situation in which it would be None. It matches the ServerName in your Apache configuration, so won't this be a reliable value to use when reconstructing an URL?To add just a tad more confusion here - don't forget ServerAlias, which isalso a perfectly valid value for the deduced URL. ;-) Grisha Exactly ! I was beginning to feel cornered into abandoning my mass virtual hosting setup, but it's clear that whenever anyone uses ServerAlias, he'll have the same problem, namely knowing what the request was in the first time. So I'll stick with req.hostname for now. Regards, Nicolas
Re: Various musings about the request URL / URI / whatever
Note that this uri can in turn be splitted in something which is lost by the publisher and the req.path_info field, that is IIRC that we can assert(req.uri.endswith(req.path_info)). I don't know what req.path_info is before the publisher kicks in, though. I'm not sure I understand what is being lost since publisher does not modify req.uri. Something that I've found useful but which seems to be missing is the idea of a base_uri, where uri = base_uri + path_info Or maybe the base_uri part is what you mean when you say something is lost? THIS is what has driven me batty...if someone could write the concise description of the relationship between req.uri and req.path_info with no ifs-ands-or-buts, exclusionary clauses and definitely no footnotes, I can stop my drinking habit. :-) Having base_uri would be heaven. Daniel Popowich --- http://home.comcast.net/~d.popowich/mpservlets/
Re: [vote] 2.2.0 tarballs
On 11/30/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 02:43:24PM -0600, William A. Rowe, Jr. wrote: It was hardly nobody, I may be shoddily inexperienced with the win32 port, but I did go to the trouble of testing apr-iconv on win32 and have been regularly building 2.1/2.2 on win32 to make sure it builds/works for me. And we've heard from others doing the same. It was close to nobody, the only reason it is released is that yourself, and Garrett both stepped up. But I posted far more pings than I received in testers, and it took two months :) Thank you two for the review, no slight intended. Wouldn't it help if (beta) binaries are posted to http://httpd.apache.org/download.cgi?
Re: Various musings about the request URL / URI / whatever
Jorey Bump wrote: Even better, deprecate req.hostname in 3.2, where we can add req.host to contain the value in req.headers_in['Host']. Then drop req.hostname in 3.3 completely. This will give developers some time to adapt. It's too late to be deprecating anything in 3.2. I know it seems like 3.2 is a codeword for some far-off future release, but we really are close to 3.2 *final*. There has been no negative feedback on 3.2.5b, so unless something bad happens we hope to have an official release in mid-December. Of 2005. :) Jim
Re: Various musings about the request URL / URI / whatever
Nicolas Lehuen writes: a) Handlers and published modules seem to behave the same way, so the computation of path_info must come from above, i.e. either from mod_python or from Apache. b) We've got req.uri == req.subprocess_env.get(SCRIPT_NAME) + req.subprocess_env.get(PATH_INFO). Cool, but who does the split ? I'm guessing that it's Apache who does it thanks to the AddHandler directives ; it knows that the .py extension must be served by mod_python, hence it deduces that /test.py must be the script name and /subpath some path info to provide the script with. This is how I conceptualize what apache does: apache takes the PATH component from the uri and appends it to DocumentRoot, it then searches down this path, starting with the first path component after DocumentRoot, testing to see if it exists on the filesystem. If it exists it continues to the next path component. If it doesn't exist and the previous component was a file, then PATH up to, but not including the current component is the script and this component to the end of PATH is the path_info. If the previous component was a directory, however, then the script goes up to and including the current component, the path_info starting with the next component ending with the end of the PATH. Confused? I was and still am, but that was what I discovered. DocumentRoot/dir1/dir2/dir3/file/some/thing/else With the above, /dir1/dir2/dir3/file would be the base_uri and /some/thing/else would be the path_info...but... DocumentRoot/dir1/dir2/dir3/some/thing/else will have /dir1/dir2/dir3/some as the script (yes, even though no such thing exists on the filesystem) and /thing/else becomes the path_info. Odd behaviour, no? It just about killed me discovering it, but it's what allows some handlers to work with clean urls (no file extensions), so I'm not complaining. :-) Daniel Popowich --- http://home.comcast.net/~d.popowich/mpservlets/
Re: AW: problems with ssl in balance/proxy mode
On 11/30/2005 11:53 AM, Matthias Behrens wrote: thx this seems to be the proper fix, but how do i apply it? which tool do i need for patching the sourcecode? sorry for asking such newby questions. i am new to opensourcedevelopment. Ok. Let me summarize: You found the reason for the problem (which was really not easy in this case) but you do not know how to apply a patch to the source code. You are using Outlook for your mail and www.gulp.de runs on a Windows version of httpd. So you must be a Windows developer :-). Jokes aside. I am working on Unix where patches are applied with patch / gpatch. I really do not know how to do this on Windows, except with cygwin :-). So some Windows developers to the rescue please! alos: can u tell me if my way of fixing the problem was wrong and why? what is it with brigades and buckets anyway? Please have a look at http://www.apachetutor.org/dev/brigades they seem to be pretty unrelieable since it is possible to make a bucket that contains a pointer to your local char variable and pass it to another function which gives the pointer to another bucket in another brigade! thats very dangerous - especially since the guy who programmed the code responsible for this bug, used the proper functions which indicate proper use of his data. [..cut..] No, this is neither unreliable nor really dangerous provided that you have a better knowledge of the concept of brigades and buckets. Brigades and buckets are passed thru filter chains. The filters do whatever work needs to be done (maybe even no work at all) on the buckets and pass them to the next filter in the chain. In the case of output filters they get finally written to the client, in the case of input filters they normally get consumed by the handler. From the call stack perspective the whole filter chain is done during one pass so pointers to local variables of functions deeper in the call stack are still valid. Sometimes a filter cannot work on the data contained in the buckets right now during this call, but it can do on one of the next calls to it when the unconsumed buckets fly by again. In this case the filter typically sets these buckets aside. For (nearly?) all bucket types there is a setaside operation defined to do just that. In the case of a transient bucket the bucket is transformed into a heap bucket, which means that the data from the transient buffer (local char in our case) is copied to a buffer on the heap and thus is still valid (provided the pool from which the heap buffer was aquired survived) during the next call of the filter. The problem you faced here, was caused by the situation that mod_proxy did not set aside the buckets it did not want to work on immediately (it tries to get enough data to make a good and safe decision on how to handle request bodies regarding content-length and transfer-encoding: chunked. See also CVE-2005-2088 on http://httpd.apache.org/security/vulnerabilities_20.html). Regards Rüdiger
Re: [vote] 2.2.0 tarballs
Olaf van der Spek wrote: Wouldn't it help if (beta) binaries are posted to http://httpd.apache.org/download.cgi? In general yes. In the case I mentioned, NO - you cannot post a candidate which hasn't received 3 +1's, and you certainly cannot push it out to the mirrors. But our alphas/betas have been pushed out to download.cgi ... Apache HTTP Server 2.1.9-beta is also available although the apr-iconv-1.x component hadn't been released in time for any beta binaries from Win32. Bill
Re: AW: problems with ssl in balance/proxy mode
On Wed, Nov 30, 2005 at 11:54:19PM +0100, Ruediger Pluem wrote: Ok. Let me summarize: You found the reason for the problem (which was really not easy in this case) but you do not know how to apply a patch to the source code. You are using Outlook for your mail and www.gulp.de runs on a Windows version of httpd. So you must be a Windows developer :-). Jokes aside. I am working on Unix where patches are applied with patch / gpatch. I really do not know how to do this on Windows, except with cygwin :-). So some Windows developers to the rescue please! Insall TortoiseSVN and use its Apply Patch feature is good, it's usually much better than the command line versions of patch that are available, and understands svn to boot. http://tortoisesvn.tigris.org/ -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
httpd 2.2 ./buildconf in the future-imperfect tense
[EMAIL PROTECTED] httpd-2.2]$ ./buildconf You don't have a copy of the apr source in srclib/apr. Please get the source using the following instructions, or specify the location of the source with --with-apr=[path to apr] : svn co http://svn.apache.org/repos/asf/apr/apr/trunk srclib/apr You don't have a copy of the apr-util source in srclib/apr-util. Please get one the source using the following instructions, or specify the location of the source with --with-apr-util=[path to apr-util]: svn co http://svn.apache.org/repos/asf/apr/apr-util/trunk srclib/apr-util This seems odd in production, especially if apr trunk might be bumped to 2.0 and we still use apr-1.x for httpd. It seems the message should recommend they obtain the appropriate tarball, or by tag. Yes, we run ./buildconf for our tarball, but it doesn't prevent the user from re-running ./buildconf and becoming confused, especially if they installed apr without a source apr tree handy anymore. Bill
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 09:22:58PM +, Nick Kew wrote: Can someone clarify: what happens *by default* if APR 1.0/1.1 is found on a target machine? If it tries to build against that, I'd support a -1. If it does something sensible - which could be emitting an error message and refusing to build - I'd not worry. It refuses to configure, you need to go build apr/apu 1.2 somewhere and reconfig with the --with-apr(-util) options. Ok, so explain to me why we wasted a MB or two distributing srclib/apr/ and srclib/apr-util/ when the result is; [EMAIL PROTECTED] httpd-2.2]$ ./configure checking for chosen layout... Apache checking for working mkdir -p... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Configuring Apache Portable Runtime library ... checking for APR... yes setting CC to gcc setting CPP to gcc -E setting CFLAGS to -g -O2 -pthread setting CPPFLAGS to -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE setting LDFLAGS to Configuring Apache Portable Runtime Utility library... checking for APR-util... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E configure: Configuring PCRE regular expression library configuring package in srclib/pcre now checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking for an ANSI C-conforming const... yes checking for size_t... yes checking for bcopy... yes checking for memmove... yes checking for strerror... yes configure: creating ./config.status config.status: creating Makefile config.status: creating pcre.h config.status: creating pcre-config config.status: creating config.h config.status: executing default commands srclib/pcre configured properly setting AP_LIBS to /local0/asf/httpd-2.2/srclib/pcre/libpcre.la setting INCLUDES to -I$(top_builddir)/srclib/pcre Configuring Apache httpd ... adding -I. to INCLUDES adding -I$(top_srcdir)/os/$(OS_DIR) to INCLUDES adding -I$(top_srcdir)/server/mpm/$(MPM_SUBDIR_NAME) to INCLUDES adding -I$(top_srcdir)/modules/http to INCLUDES adding -I$(top_srcdir)/modules/filters to INCLUDES adding -I$(top_srcdir)/modules/proxy to INCLUDES adding -I$(top_srcdir)/include to INCLUDES adding -I$(top_srcdir)/modules/generators to INCLUDES adding -I$(top_srcdir)/modules/mappers to INCLUDES adding -I$(top_srcdir)/modules/database to INCLUDES adding -I/usr/local/include/apr-1 to INCLUDES Applying OS-specific hints for httpd ... forcing SINGLE_LISTEN_UNSERIALIZED_ACCEPT to 1 forcing AP_NONBLOCK_WHEN_MULTI_LISTEN to 1 checking for rm... /bin/rm checking for pkg-config... /usr/bin/pkg-config checking for rsync... /usr/bin/rsync checking for gawk... gawk checking whether ln -s works... yes checking for ranlib... ranlib checking for lynx... lynx checking for egrep... grep -E checking for AIX... no checking for library containing strerror... none required checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking for APR version 1.2.0 or later... no configure: error: APR version 1.2.0 or later is required This appears to be the worst of both worlds. -1 for release of the proposed tarball in this state. Drop the srclib's or make the srclib's work, it doesn't that much matter to me. But the above is sillyness at it's worst. Bill
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 09:22:58PM +, Nick Kew wrote: Can someone clarify: what happens *by default* if APR 1.0/1.1 is found on a target machine? If it tries to build against that, I'd support a -1. If it does something sensible - which could be emitting an error message and refusing to build - I'd not worry. It refuses to configure, you need to go build apr/apu 1.2 somewhere and reconfig with the --with-apr(-util) options. Ok, now what the heck? [EMAIL PROTECTED] httpd-2.2]$ configure: error: APR-util version 1.2.0 or later is required ./configure --prefix=/usr/local --with-apr=srclib/apr --with-apr-util=srclib/apr-util checking for chosen layout... Apache [...] checking for APR version 1.2.0 or later... yes checking for APR-util version 1.2.0 or later... no configure: error: APR-util version 1.2.0 or later is required [EMAIL PROTECTED] httpd-2.2]$ ls -al srclib total 48 drwxrwxr-x 4 wrowe wrowe 4096 Nov 30 18:32 . drwxrwxr-x 12 wrowe wrowe 4096 Nov 30 18:34 .. lrwxrwxrwx 1 wrowe wrowe 19 Nov 30 18:32 apr - /local0/asf/apr-1.2 lrwxrwxrwx 1 wrowe wrowe 24 Nov 30 18:32 apr-util - /local0/asf/apr-util-1.2 [...] [EMAIL PROTECTED] httpd-2.2]$ grep VERSION srclib/apr-util/apu-1-config APRUTIL_MAJOR_VERSION=1 APRUTIL_DOTTED_VERSION=1.2.3 Explanations?
Re: [vote] 2.2.0 tarballs
On Wed, Nov 30, 2005 at 06:33:51PM -0600, William A. Rowe, Jr. wrote: Ok, so explain to me why we wasted a MB or two distributing srclib/apr/ and srclib/apr-util/ when the result is; That's not the result when you don't have apr/apu 1.x [x:2] installed. apr and apr-util 1.2 are bundled for reasons of pragmatic convienence, recognising that the vast majority of people don't have these already. If apr 1.0 or 1.1 happen to be installed, I don't see why it's not reasonable to fail to configure. The administrator may intend to link against the system version, they may not want httpd having its own libapr. And they're the only people capable of making that decision and hence resolving the conflict. They can decide to install over their existing apr, or to install a new one just for httpd. I brought this exact issue up weeks ago, and it didn't go very far. I was originally -1, for the very same reasons you are, but having thought about it decided that yes, while the present system introduces some inconvienence for a small fraction of users, it doesn't try to second guess them either, and unbundling apr/apr-util would represent a huge inconvienence to a large fraction of users. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
On Wed, Nov 30, 2005 at 06:39:30PM -0600, William A. Rowe, Jr. wrote: Ok, now what the heck? Looks like you've pointed the --with-apr options at trees which have been built, but arn't installed targets. find_apr.m4 tests for bin/apr-1-config -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
On Thu, Dec 01, 2005 at 12:59:12AM +, Colm MacCarthaigh wrote: On Wed, Nov 30, 2005 at 06:39:30PM -0600, William A. Rowe, Jr. wrote: Ok, now what the heck? Looks like you've pointed the --with-apr options at trees which have been built, but arn't installed targets. find_apr.m4 tests for bin/apr-1-config Actually no, sorry, it should test for both. configuring the bundled apr, apr-util and then using the --with-apr and --with-apr-util options works for me. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote: If apr 1.0 or 1.1 happen to be installed, I don't see why it's not reasonable to fail to configure. The administrator may intend to link against the system version, they may not want httpd having its own libapr. And they're the only people capable of making that decision and hence resolving the conflict. They can decide to install over their existing apr, or to install a new one just for httpd. I brought this exact issue up weeks ago, and it didn't go very far. I was originally -1, for the very same reasons you are, but having thought about it decided that yes, while the present system introduces some inconvienence for a small fraction of users, it doesn't try to second guess them either, and unbundling apr/apr-util would represent a huge inconvienence to a large fraction of users. I read this a bit backwards of your interpretation; * admins who install 1.1 for some specific reason are responsible to ensure they deal with the new package correctly (e.g., we give them a message upon configure Found old APR 1.1.0, installing APR 1.2.2 for you and let them decide what to do. 99% of the time, they must follow our advise and install 1.2.2 in the same prefix/ as httpd.) * the vast majority of users, who only have apr 1.0/1.1 due to svn or other intrapackage dependencies, get a free apr 1.2 without having to think about it. Make this whole headache a noop for them. And I for one don't want the headaches of the users@ trouble reports. I'd really prefer to see those who help out on users@ answering this objection, as opposed to the hackers who are detached from the user community pushing this out +1 over those user-supporters objections. Bill
Re: [vote] 2.2.0 tarballs
On Wed, Nov 30, 2005 at 07:10:37PM -0600, William A. Rowe, Jr. wrote: * admins who install 1.1 for some specific reason are responsible to ensure they deal with the new package correctly (e.g., we give them a message upon configure Found old APR 1.1.0, installing APR 1.2.2 for you and let them decide what to do. 99% of the time, they must follow our advise and install 1.2.2 in the same prefix/ as httpd.) * the vast majority of users, who only have apr 1.0/1.1 due to svn or other intrapackage dependencies, get a free apr 1.2 without having to think about it. Make this whole headache a noop for them. And I for one don't want the headaches of the users@ trouble reports. I'd really prefer to see those who help out on users@ answering this objection, as opposed to the hackers who are detached from the user community pushing this out +1 over those user-supporters objections. User trouble reports can be easily mitigated by including the instructions; If you are installing on a system with apr/apr-util 1.0 or 1.1 installed, you must provide apr 1.2 manually. You can decide to upgrade your existing apr/apr-util installation(s) to 1.2, or may use the bundled versions like so; cd srclib/apr ; ./configure cd srclib/apr-util ; ./configure --with-apr=../apr ./configure --with-apr=srclib/apr --with-apr-util=srclib/apr-util in the release notes. There's no reason why this can't be fixed during 2.2, but with a months old issue, and no sign of a patch, should it hold up a GA? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [vote] 2.2.0 tarballs
On Nov 30, 2005, at 4:39 PM, William A. Rowe, Jr. wrote: ./configure --prefix=/usr/local --with-apr=srclib/apr --with-apr- util=srclib/apr-util checking for chosen layout... Apache [...] checking for APR version 1.2.0 or later... yes checking for APR-util version 1.2.0 or later... no configure: error: APR-util version 1.2.0 or later is required Heh. apr-util checks for apr in ../apr, which is broken behaviour. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [vote] 2.2.0 tarballs
On Thu, Dec 01, 2005 at 01:25:38AM +, Colm MacCarthaigh wrote: There's no reason why this can't be fixed during 2.2, but with a months old issue, and no sign of a patch, should it hold up a GA? No way. -- justin
[STATUS] (httpd-2.0) Wed Nov 30 23:49:14 2005
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2005-11-21 15:22:22 -0500 (Mon, 21 Nov 2005) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS Consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS Consult the trunk/ for all new development and documentation efforts: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Release history: 2.0.56 : in development 2.0.55 : released October 16, 2005 as GA. 2.0.54 : released April 17, 2005 as GA. 2.0.53 : released February 7, 2005 as GA. 2.0.52 : released September 28, 2004 as GA. 2.0.51 : released September 15, 2004 as GA. 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 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 as beta. 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 Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: * Forward binary compatibility is expected of Apache 2.0.x releases, such that no MMN major number changes will occur. Such changes can only be made in the trunk. * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, get feedback and votes on list or in STATUS, then merge into branches/2.2.x, and finally merge into branches/2.0.x, as applicable. RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] *) mod_actions: Regression from 1.3: the file referred to must exist. Solve this by introducing the virtual modifier to the Action directive. PR 28553. modules/mappers/mod_actions.c: r1.32, r1.34 jerenkrantz: Icky side-effect of the *t == '0' check. +1: nd, jerenkrantz, wrowe, jim -0: by rbb (inconsistent to 1.3, discussion on dev@) nd: I'm going to reverse the default jerenkrantz, striker: I'm confused as to the status of this backport. *) support/check_forensic: Fix tempfile usage svn rev 125495, 126224 jerenkrantz says: r126224 fixes brokenness with r125495 on Solaris. +1: thommay, jerenkrantz, trawick trawick: which isn't portable; I've suggested a work-around on dev@
[STATUS] (httpd-2.1) Wed Nov 30 23:50:36 2005
APACHE 2.3 STATUS: -*-text-*- Last modified at [$Date: 2005-11-13 02:22:18 -0500 (Sun, 13 Nov 2005) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS Patches considered for backport are noted in their branches' STATUS: * http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS Release history: [NOTE that only Alpha/Beta releases occur in 2.3 development] 2.3.0 : in development Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: * Handling of non-trailing / config by non-default handler is broken http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2 jerenkrantz asks: Why should this block a release? wsanchez agrees: this may be a change in behavior, but isn't clearly wrong, and even if so, it doesn't seem like a showstopper. * the edge connection filter cannot be removed http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2 jerenkrantz asks: Why should this block a release? stas replies: because it requires a rewrite of the filters stack implementation (you have suggested that) and once 2.2 is released you can't do that anymore. CURRENT VOTES: * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - prefer httpd.default.conf to avoid ambiguity with cvs b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken, nd (prefer the latter), erikabele +1: wsanchez (propose sysconfdir/examples/version for diffiness) d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - diff is wonderful when comparing old/new default configs, even for customized sites that ianh mentions jim - ... assuming that the default configs have been updated with the required inline docs to explain the changes * If the parent process dies, should the remaining child processes gracefully self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a hot spare). See: Message-ID: [EMAIL PROTECTED] Self-destruct: Ken, Martin, Lars Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd /* The below was a concept on *how* to handle the problem */ Have 2 parents: +1: jim -1: Justin, wrowe, rederpj, nd +0: Lars, Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker, wrowe, nd +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing), rederpj, jim -0: Lars pquerna: Do we want to change this for 2.2? RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Patches submitted to the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable * Filter stacks and subrequests,
Re: [vote] 2.2.0 tarballs
Sander Temme wrote: On Nov 30, 2005, at 4:39 PM, William A. Rowe, Jr. wrote: ./configure --prefix=/usr/local --with-apr=srclib/apr --with-apr- util=srclib/apr-util checking for chosen layout... Apache [...] checking for APR version 1.2.0 or later... yes checking for APR-util version 1.2.0 or later... no configure: error: APR-util version 1.2.0 or later is required Heh. apr-util checks for apr in ../apr, which is broken behaviour. I'm seeing this too... ./buildconf --with-apr=srclib/apr --with-apr-util=srclib/apr-util found apr source: srclib/apr found apr-util source: srclib/apr-util rebuilding srclib/apr/configure buildconf: checking installation... buildconf: python version 2.3.4 (ok) buildconf: autoconf version 2.59 (ok) buildconf: libtool version 1.5.20 (ok) Copying libtool helper files ... buildconf: Using libtool.m4 at /usr/local/share/aclocal/libtool.m4. Creating include/arch/unix/apr_private.h.in ... Creating configure ... Generating 'make' outputs ... rebuilding rpm spec file rebuilding srclib/apr-util/configure Problem finding apr source in ../apr. Use: --with-apr=[directory] ./buildconf failed for apr-util
Re: [vote] 2.2.0 tarballs
Colm MacCarthaigh wrote: There's no reason why this can't be fixed during 2.2, but with a months old issue, and no sign of a patch, should it hold up a GA? I'm 100% conviced next to nobody on this list has been developing and testing httpd-2.2/apr-1.2 without their own in-tree tweaks. I'm as guilty as anyone. So we've been compiling and improving the code, but the build/install status is -worse- than httpd-2.0, ergo this is not the best version of apache now available and is -not- ready for GA. Those hyper to release, why not make it usable by Joe anybody instead of only httpd-dev hacker who's used to 'fudging the build'? Bill
Re: [vote] 2.2.0 tarballs
On Nov 30, 2005, at 10:10 PM, William A. Rowe, Jr. wrote: Sander Temme wrote: On Nov 30, 2005, at 4:39 PM, William A. Rowe, Jr. wrote: ./configure --prefix=/usr/local --with-apr=srclib/apr --with-apr- util=srclib/apr-util checking for chosen layout... Apache [...] checking for APR version 1.2.0 or later... yes checking for APR-util version 1.2.0 or later... no configure: error: APR-util version 1.2.0 or later is required Heh. apr-util checks for apr in ../apr, which is broken behaviour. I'm seeing this too... ./buildconf --with-apr=srclib/apr --with-apr-util=srclib/apr-util found apr source: srclib/apr found apr-util source: srclib/apr-util rebuilding srclib/apr/configure buildconf: checking installation... buildconf: python version 2.3.4 (ok) buildconf: autoconf version 2.59 (ok) buildconf: libtool version 1.5.20 (ok) Copying libtool helper files ... buildconf: Using libtool.m4 at /usr/local/share/aclocal/libtool.m4. Creating include/arch/unix/apr_private.h.in ... Creating configure ... Generating 'make' outputs ... rebuilding rpm spec file rebuilding srclib/apr-util/configure Problem finding apr source in ../apr. Use: --with-apr=[directory] ./buildconf failed for apr-util I'm looking at this. If you give that apu buildconf the right --with- apr parameter, buildconf completes. The problem is, if the apr_src_dir is relative, when we call buildconf we have already descended into srclib/apr-util so the relative reference is broken. I'm trying to wrap my common cold-addled brain around this and hope to have a patch by the time this episode of Law Order is over. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [vote] 2.2.0 tarballs
On Nov 30, 2005, at 10:12 PM, William A. Rowe, Jr. wrote: I'm 100% conviced next to nobody on this list has been developing and testing httpd-2.2/apr-1.2 without their own in-tree tweaks. I'm as guilty as anyone. So we've been compiling and improving the code, but the build/ install status is -worse- than httpd-2.0, ergo this is not the best version of apache now available and is -not- ready for GA. I just built from scratch using the tarball and the same options that any typical user would set: i.e., ./configure --prefix=/dist/test22 --enable-modules=all Zero problems. I don't understand what you are talking about -- developers don't run ./buildconf on the source package. Only we do that. Even after I do a make extraclean ./buildconf ./configure --prefix=/dist/test22 --enable-modules=most again I have zero problems. The included versions of apr and apr-util are used in all of my tests. I've never installed apr-1.x in the OS system libraries. Why would anyone outside this list do that? Those hyper to release, why not make it usable by Joe anybody instead of only httpd-dev hacker who's used to 'fudging the build'? Whatever problem you are encountering, please fix it on trunk. I see no evidence that it will cause people outside the APR core development group any grief for httpd-2.2, and even then a workaround can be described on the website. Roy
Re: [vote] 2.2.0 tarballs
Justin Erenkrantz wrote: On Wed, Nov 30, 2005 at 10:35:07PM -0800, Sander Temme wrote: I'm looking at this. If you give that apu buildconf the right --with- apr parameter, buildconf completes. The problem is, if the Just to reiterate - buildconf is not necessary for users to run. Therefore, if it's broken for 2.2.0, it's not a showstopper. -- justin Is buildconf present? If the user runs it, does it corrupt the unpacked tree? If this is so, and it's broken, then perhaps remove buildconf throughout the tree, and the autoconf source files, resulting in a vanilla ./configure for the resulting distribution package?
Re: [vote] 2.2.0 tarballs
On Nov 30, 2005, at 10:53 PM, William A. Rowe, Jr. wrote: Justin Erenkrantz wrote: On Wed, Nov 30, 2005 at 10:35:07PM -0800, Sander Temme wrote: I'm looking at this. If you give that apu buildconf the right -- with- apr parameter, buildconf completes. The problem is, if the Just to reiterate - buildconf is not necessary for users to run. Therefore, if it's broken for 2.2.0, it's not a showstopper. -- justin Is buildconf present? If the user runs it, does it corrupt the unpacked tree? If this is so, and it's broken, then perhaps remove buildconf throughout the tree, and the autoconf source files, resulting in a vanilla ./ configure for the resulting distribution package? Hm... you kinda need it if you drop in a custom module with its config5.m4 foo. Or if you want to build with a different libtool than httpd came with. I agree that's kinda deep though. I wouldn't hold up the release for it. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [vote] 2.2.0 tarballs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 28, 2005, at 11:55 PM, Paul Querna wrote: Available from: http://people.apache.org/~pquerna/dev/httpd-2.2.0/ Please vote on releasing as GA/Stable. +1 for release as 2.2.0. I have verified the signatures, compared the contents, diffed versus the post-tarball httpd-2.2 changes, and tested on OS X 10.4.3 using Xcode 2.2. You can add the following signatures to the asc files if you like, minus the indent, assuming you can verify them afterward). httpd-2.2.0.tar.bz2.asc: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQBDjqBqW5aAEOBPmokRAmt6AJ0VpGAZAeSw6sDKp/NftIVFFeaF4ACeL+CB Ljif/NCrZXEpktnVTt3uCPs= =mtfD -END PGP SIGNATURE- httpd-2.2.0.tar.gz.asc: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQBDjqBXW5aAEOBPmokRAlXHAKCUE/dZdsXikx11CuYkBoCr28WYqgCfYuTv +qPQnF9uCcmV+n/ZUFW8jTo= =HJ0S -END PGP SIGNATURE- Cheers, Roy T. Fieldinghttp://roy.gbiv.com/ Chief Scientist, Day Software http://www.day.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDjqMxW5aAEOBPmokRAiouAKCH5He8ly1ngnyUcM+CB2F6tTjpHgCdHfzy +XMSmJzDWHeA4GI9K09w+Fs= =SNvw -END PGP SIGNATURE-
Re: [vote] 2.2.0 tarballs
On Thu, Dec 01, 2005 at 12:53:22AM -0600, William A. Rowe, Jr. wrote: Is buildconf present? If the user runs it, does it corrupt the unpacked tree? Um. Have you even *tried* to run './buildconf' in an extracted httpd 2.2.0 tarball? I have - guess what? It works just fine. Therefore, there is no corruption. The default case with no arguments works exactly as expected. It only goes wonky if you give it bad arguments. It might not be as robust as we might like (the fact that it switches directories means passing --with-apr doesn't work as expected - yawn - don't specify the args!). The case remains that the default arguments (i.e. none) to buildconf work. If this particular corner case bugs you so much, you can go and commit a fix yourself - I'll even vote for it to be backported for 2.2.1. Still, I've yet to see a single issue - including this one - raised that would cause to me to even consider changing my +1 vote for GA. -- justin
