[ANNOUNCE] libapreq2-2.06-dev Released
libapreq2-2.06-dev Released The Apache Software Foundation and The Apache HTTP Server Project are pleased to announce the 2.06-dev release of libapreq2. This Announcement notes significant changes introduced by this release. libapreq2-2.06-dev is released under the Apache License version 2.0. It is now available through the ASF mirrors http://httpd.apache.org/apreq/download.cgi and has entered the CPAN as file: $CPAN/authors/id/J/JO/JOESUF/libapreq2-2.06-dev.tar.gz size: 711422 bytes md5: e245db341c4967e0a23b7f767d6486d9 libapreq2 is an APR-based shared library used for parsing HTTP cookies, query-strings and POST data. This package provides 1) version 2.1.3 of the libapreq2 library, 2) mod_apreq2, a filter module necessary for using libapreq2 within the Apache HTTP Server, 3) the Apache2::Request, Apache2::Cookie, and Apache2::Upload perl modules for using libapreq2 with mod_perl2. Changes with libapreq2-2.06-dev (released July 20, 2005) - C API [Marc Gràcia, joes] Fix apreq_decode(v) when iso-latin-1 chars appear at the end of an encoded string. - Perl API [Philip M. Gollucci] Fix Attempt to free temp prematurely error in apreq_xs_croak(). - C API [Philip M. Gollucci] Add mod_apreq2 to httpd's server tokens. - Perl API [joes] Drop support for $req-env(), which also died with 2.05-dev. - Perl API [joes] Support for table set/add/delete methods is formally withdrawn. Technically this feature died with the module API refactoring in 2.05-dev. - C API [max] Right-hand limit of apreq_brigade_move() is declared as excluding, but APR_RING_UNSPLICE() wants an including right-hand limit. Fixed this by passing the previous bucket. - Perl API [joes] Drop support for Apache2::Request::new's HOOK_DATA. UPLOAD_HOOK now takes only two arguments: ($upload, $data). - Perl API [joes] Drop support for Apache2::Cookie::Jar::new's VALUE_CLASS. 2.05-dev broke that API, and it's not worth trying to fix. People who need that should use APR::Request::Cookie::Table's cookie_class() API instead. - Perl API [joes] Fix cookie domain/path munging in Apache2::Cookie::new().
Re: svn commit: r209837 - /httpd/apreq/trunk/include/apreq_version.h
Philip M. Gollucci [EMAIL PROTECTED] writes: #define APREQ_MINOR_VERSION 1 /** patch level */ -#define APREQ_PATCH_VERSION 1 +#define APREQ_PATCH_VERSION 2 speaking of which shouldn't the patchlevel be at 4 at this point ? I'm probably not grasping how apreq is using this though. The rules are simple: The patch version should get bumped whenever a commit modifies a library/*.c file. The minor version gets bumped, and the patch version zeroed, whenever a commit modifies an include/*.h file. I wrote some of this down in FAQ.pod. -- Joe Schaefer
Re: mod-cache-requestor plan
Hi All,
We are now almost at consesus about this new mod-cache-requester
module's mechanism. and now I believe its good time to start
implementing the module.
But before I could do that, I need some help from you guys.
- I am now comfortable with mod-cache, mod-mem-cache, cache_storage.c,
cache_util.c etc.
- But still not too sure how to implement couple of things.
1. How to start the new thread/process for mod-cache-requester when
server start. any similar piece of code would help me a lot.
2. how mod-cache-requester can generate the sub request just to reload
the content in the cache.
3. In current scheme, whenever mod-cache-requester pulls first entry
from pqueue ('refresh' queue) it re-requests it to reload. now by the
time this re-request is done, page might actually have been expired
and removed from cache. in such case should mod-cache reload it or
should wait for next legitimate request.
Your thoughts on any/all on these issues would be really helpful.
Thanks
Parin.
On 7/19/05, Ian Holsman [EMAIL PROTECTED] wrote:
Parin Shah wrote:
you should be using a mix of
# requests
last access time
cost of reproducing the request.
Just to double check, we would insert entry into the 'refresh queue'
only if the page is requested and the page is soon-to-be-expired. once
it is in the queue we would use above parameters to calculate the
priority. Is this correct? or let me know If I have mistaken it.
yep.
thats the idea.
refresh the most-popular pages first.
see memcache_gdsf_algorithm() in mod_mem_cache.c for an implementation
of this, which assumes 'length' of request is related to the cost of
reproducing the request.
the priority queue implementation is sitting in mod_mem_cache, and could
be used to implement the 'refresh' queue I would think.
I feel comfortable with mod-cache and mod-mem-cache code now. but we
also need to start new thread/process for mod-cache-requester when
server starts. I am not too sure how we could implement it. any
pointers to the similar piece of code would be really helpful to me.
I don't have any code which does this to share with you (others might
know of some).
Thanks,
Parin.
--Ian
Re: NTLM HTTP Authentication is insecure by design - a new writeup by Amit Klein
At 03:57 AM 7/19/2005, Roy T. Fielding wrote: On Jul 18, 2005, at 12:30 PM, William A. Rowe, Jr. wrote: NTLM HTTP Authentication (and possibly other connection-oriented HTTP authentication and authorization protocols) is insecure by design Yep, no shit -- that's what the Microsoft fools were told when they introduced it. That doesn't surprise me :) *) The web server (IIS/6.0) must receive a Via-less request. The Microsoft implementation assumes that the Via header is always sent by a proxy server, and this is indeed mandated by the HTTP/1.1 RFC 2616 (http://www.ietf.org/rfc/rfc2616.txt), section 14.45: The Via general-header field MUST be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests [...] Yep. However, it seems that not all servers adhere to this standard. For example, Apache 2.0.54 mod_proxy does not generate a Via header by default (see the ProxyVia directive - http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxyvia, yet the default httpd.conf file contains a commented-out ProxyVia On directive, so it's possible that many Apache proxy deployments do WTF? That's a bug. I'd say. The question is; what's the fix? Today's syntax is ProxyVia on|off|full|block The default is off, which is clearly invalid. A default of full might be overkill, default of on should be sufficient Are ProxyVia off and ProxyVia block invalid? Technically, it's pretty clear that they are. Realistically, if someone wants an invisible proxy, I guess that's up to them, but then again it's their own damned fault if they trip over something like this. But we don't give them much choice today, I don't think... The 14.45 Via section defines a pretty clear acceptable flavor, [...] The received-by field is normally the host and optional port number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to be sensitive information, it MAY be replaced by a pseudonym. If the port is not given, it MAY be assumed to be the default port of the received-protocol. Sooo... a new alternative, ProxyVia alias shortname would seem sane, and a much better choice for most reverse proxies. For organizations that have strong privacy requirements for hiding internal structures, a proxy MAY combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. For example, Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy could be collapsed to Via: 1.0 ricky, 1.1 mertz, 1.0 lucy Applications SHOULD NOT combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced by pseudonyms. Applications MUST NOT combine entries which have different received-protocol values. Sooo... ProxyVia collapse shortname would be an even terser flavor, and I can't see a case where we would keep the truename of this via server while collapsing the rest. Thoughts? Bill
Re: svn commit: r219520 - /httpd/httpd/branches/2.2.x/
On Mon, Jul 18, 2005 at 11:58:21AM -0500, William Rowe wrote: Thanks Paul, you just collided with the refactoring of 2.1.x proxy. Is this refactoring complete? Apart from the compiler warnings, a bunch of the t/ssl/proxy.t tests have started failing with the trunk code. With worker, the server is dumping core: (this seems to be a regression since 2005-07-15, when all the tests were passing with both prefork and worker) Core was generated by `/tmp/regressk13532/trunk-worker-root/bin/httpd -d /tmp/regressk13532/pf-trunk-w'. Program terminated with signal 11, Segmentation fault. [...omitting other threads...] #0 0x0032e452e989 in kill () from /lib64/tls/libc.so.6 No symbol table info available. #1 signal handler called No symbol table info available. #2 apr_pool_clear (pool=0x0) at memory/unix/apr_pools.c:332 freelist = (apr_memnode_t *) 0x0 max_index = 2 max_free_index = 0 next = (apr_memnode_t *) 0x56a3e8 index = 0 current_free_index = 4294967295 #3 0x002a97de8e31 in connection_cleanup (theconn=0x56a3e8) at proxy_util.c:1456 p = (apr_pool_t *) 0x80db08 conn = (proxy_conn_rec *) 0x809cd8 worker = (proxy_worker *) 0x5a0328 #4 0x002a97de95a6 in ap_proxy_release_connection (proxy_function=0x56a3e8 \001, conn=0x809cd8, s=0x0) at proxy_util.c:1714 No locals. #5 0x002a980fd6c8 in ap_proxy_http_cleanup (scheme=0x0, r=0x89e4d8, backend=0x809cd8) at mod_proxy_http.c:1525 No locals. #6 0x002a980fe910 in proxy_http_handler (r=0x89e4d8, worker=0x5a0328, conf=0x878b88, url=0x891168 /require-ssl-cgi/env.pl, proxyname=0x0, proxyport=0) at mod_proxy_http.c:1162 here = (struct apr_bucket *) 0x0 status = 0 server_portstr = :8541\000\000\000Húj\225*\000\000\000\000\000\000\000\210\213\207\000\000\000\000 scheme = 0x0 proxy_function = 0x2a980fee00 HTTPS u = 0x0 backend = (proxy_conn_rec *) 0x809cd8 is_ssl = 1 p = (apr_pool_t *) 0x8903f8 uri = (apr_uri_t *) 0x8910a8 #7 0x002a97de3786 in proxy_run_scheme_handler (r=0x89e4d8, worker=0x5a0328, conf=0x878b88, url=0x8a0066 https://localhost.localdomain:8532/require-ssl-cgi/env.pl;, proxyhost=0x0, proxyport=0) at mod_proxy.c:1890 pHook = (proxy_LINK_scheme_handler_t *) 0x589448 n = 0 rv = 0
Re: Pondering strings in Apache 3.x
* Brian Pane wrote: And although I like the performance benefits of the pool memory allocators, I remember how tricky it was to debug some of the pool and bucket lifetime problems that we encountered during the development of 2.0 (especially in filters). All things considered, I don't think I'd mind the overhead of a garbage collection thread. The pool problems should be solved now... (mostly) Thus I can't help but wonder: Would 3.0 be a good time to consider trying a Java-based httpd? If you ask me: Nope. Try Tomcat instead ;) What we need for 3.0 is just a clean design and definitions of what is core (not much, imo) and what is not core. This was started for 2.0 but never finished. Further a standardized exception handling would be nice (like svn's). The core could provide several convenience data types like ap_string_t. I would, btw, just store the length of the string in such a type. Other properties (url-encoding state, ...) imo belong to a different layer. Like a bucket or just a wrapper type. nd -- Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine beiden Gefährten nicht zu zählen brauchte -- Karl May, Winnetou III Im Westen was neues: http://pub.perlig.de/books.html#apache2
RE: mod-cache-requestor plan
Hi I can just tell you something on point #2.
In my opinion mod-cache-requester should pass in the regeneration request
what a normal user should pass to the system (e.g. cookies, header variables
and so on) because a portion of these data can be relevant in order to
generate the page correctly.
mod-cache currently keeps track of HTTP response (header and body), I think
the best is to keep track of HTTP request too in order to re-run a copy of
it to regenerate the page.
Does it makes sense?
Sergio
-Original Message-
From: Parin Shah [mailto:[EMAIL PROTECTED]
Sent: mercoledì 20 luglio 2005 8.34
To: dev@httpd.apache.org
Subject: Re: mod-cache-requestor plan
Hi All,
We are now almost at consesus about this new mod-cache-requester
module's mechanism. and now I believe its good time to start
implementing the module.
But before I could do that, I need some help from you guys.
- I am now comfortable with mod-cache, mod-mem-cache, cache_storage.c,
cache_util.c etc.
- But still not too sure how to implement couple of things.
1. How to start the new thread/process for mod-cache-requester when
server start. any similar piece of code would help me a lot.
2. how mod-cache-requester can generate the sub request just to reload
the content in the cache.
3. In current scheme, whenever mod-cache-requester pulls first entry
from pqueue ('refresh' queue) it re-requests it to reload. now by the
time this re-request is done, page might actually have been expired
and removed from cache. in such case should mod-cache reload it or
should wait for next legitimate request.
Your thoughts on any/all on these issues would be really helpful.
Thanks
Parin.
On 7/19/05, Ian Holsman [EMAIL PROTECTED] wrote:
Parin Shah wrote:
you should be using a mix of
# requests
last access time
cost of reproducing the request.
Just to double check, we would insert entry into the 'refresh queue'
only if the page is requested and the page is soon-to-be-expired. once
it is in the queue we would use above parameters to calculate the
priority. Is this correct? or let me know If I have mistaken it.
yep.
thats the idea.
refresh the most-popular pages first.
see memcache_gdsf_algorithm() in mod_mem_cache.c for an implementation
of this, which assumes 'length' of request is related to the cost of
reproducing the request.
the priority queue implementation is sitting in mod_mem_cache, and could
be used to implement the 'refresh' queue I would think.
I feel comfortable with mod-cache and mod-mem-cache code now. but we
also need to start new thread/process for mod-cache-requester when
server starts. I am not too sure how we could implement it. any
pointers to the similar piece of code would be really helpful to me.
I don't have any code which does this to share with you (others might
know of some).
Thanks,
Parin.
--Ian
Apache for win64
Hi, Does anybody know if there is an Apache binary installer for Win64 somewhere? If not, does the win32 source work for win64 as well out of the box? Thanks, --Gopi
Re: Apache for win64
No x64 binaries, But the win32 source should work fine. Jorge - Original Message - From: Gopikrishnan Sidhardhan [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Wed, 20 Jul 2005 11:54:43 +0200 Subject: Apache for win64 Hi, Does anybody know if there is an Apache binary installer for Win64 somewhere? If not, does the win32 source work for win64 as well out of the box? Thanks, --Gopi
Re: Apache for win64
Tried building it. Went on for some time, with lots of warnings like conversion from size_t to DWORD: possible loss of data. Then the build broke with fatal error LNK1112: module machine type 'AMD64' conflicts with target machine type 'X86'. Any ideas, anyone? Thanks, --Gopi Jorge Schrauwen wrote: No x64 binaries, But the win32 source should work fine. Jorge - Original Message - From: Gopikrishnan Sidhardhan [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Wed, 20 Jul 2005 11:54:43 +0200 Subject: Apache for win64 Hi, Does anybody know if there is an Apache binary installer for Win64 somewhere? If not, does the win32 source work for win64 as well out of the box? Thanks, --Gopi
httpd-1.3 patchlets
Two very small patches against 1.3.
First one, make ab default to the highest SSL version available:
Index: src/support/ab.c
===
--- src/support/ab.c(revision 125243)
+++ src/support/ab.c(working copy)
@@ -1655,7 +1655,7 @@
#ifdef USE_SSL
SSL_library_init();
-if (!(ctx = SSL_CTX_new(SSLv2_client_method( {
+if (!(ctx = SSL_CTX_new(SSLv23_client_method( {
fprintf(stderr, Could not init SSL CTX: );
ERR_print_errors_fp(stderr);
exit(1);
Secondly, a patch that keeps --without-execstrip from stripping the
httpd binary:
Index: configure
===
--- configure (revision 219524)
+++ configure (working copy)
@@ -927,6 +927,8 @@
;;
--without-execstrip)
iflags_program=`echo $iflags_program | sed -e 's/-s//'`
+iflags_core=`echo $iflags_core | sed -e 's/-S//' -e 's/
\-S\//'`
+iflags_dso=`echo $iflags_dso | sed -e 's/-S//' -e 's/
\-S\//'`
;;
--suexec-caller=*)
suexec_caller=$apc_optarg
There is a special case for Darwin in configure that makes the httpd
binary get stripped even if --without-execstrip is specified. This
stops that from happening, so --without-execstrip leaves all binaries
unstripped. I think this adheres to the principle of least astonishment.
Let me know if you can fudge that in. (:
Thanks,
S.
--
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
--
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Initial mod_smtpd code.
Jem Berkes wrote: I could also start work on a mod_smtpd_dnsbl if the mentors feel that is worthwhile? This would look up a connecting IP address against a blacklist and return a descriptive string to mod_smtpd if the client should be rejected with an error: 550 5.7.1 Email rejected because 127.0.0.2 is listed by sbl-xbl.spamhaus.org I'd also like to include support for RHSBL, a newer type of listing by domain names from the envelope sender address. That's used by a growing number of projects. Overall blacklists aren't that effective and cause a lot of false positives. They may make sense in the case of something like SpamAssassin which uses a blacklist in conjunction with other false positives, but by themselves they really aren't a responsible way of dealing with the spam problem. I think it's better to discourage worst practices than to sucumb to plugin mania.
Re: Initial mod_smtpd code.
Overall blacklists aren't that effective and cause a lot of false positives. They may make sense in the case of something like SpamAssassin which uses a blacklist in conjunction with other false positives, but by themselves they really aren't a responsible way of dealing with the spam problem. I think it's better to discourage worst practices than to sucumb to plugin mania. Blocklists aren't fundamentally broken, they are a tool which can be used properly or misused (just like many other tools). Many admins choose to maintain their own DNSBLs for one reason or another. It may be a way to control relay access based on their own subscriber IP addressess. At my site we keep a record of IPs that have persistently abused our site over the past few days. i.e. DNSBL != (SPEWS or MAPS or whatever)
Re: mod-cache-requestor plan
Parin Shah wrote: 2. how mod-cache-requester can generate the sub request just to reload the content in the cache. Look inside mod_include - it uses subrequests to be able to embed pages within other pages. Regards, Graham --
[PATCH] mod_disk_cache: change handling of varied contents
The attached patch changes how we store the contents of a varied URI.
If a URI is varied, all variations will be stored underneath a new
hash.header.vary/ directory.
This enables future tools, such as the ability to easily delete a URI
from the cache, without scanning the entire tree, just to find the
possible varied versions.
The code was written pretty quickly, and I would love some feedback both
on the idea, and the hacky way I did it :)
-Paul
Index: modules/cache/mod_disk_cache.c
===
--- modules/cache/mod_disk_cache.c (revision 219914)
+++ modules/cache/mod_disk_cache.c (working copy)
@@ -50,8 +50,8 @@
* CRLF
*/
-#define VARY_FORMAT_VERSION 1
-#define DISK_FORMAT_VERSION 2
+#define VARY_FORMAT_VERSION 3
+#define DISK_FORMAT_VERSION 4
typedef struct {
/* Indicates the format of the header struct stored on-disk. */
@@ -76,6 +76,7 @@
typedef struct disk_cache_object {
const char *root;/* the location of the cache directory */
char *tempfile;/* temp file tohold the content */
+const char *prefix;
const char *datafile;/* name of file where the data will go */
const char *hdrsfile;/* name of file where the hdrs will go */
const char *hashfile;/* Computed hash key for this URI */
@@ -124,6 +125,8 @@
*/
#define CACHE_HEADER_SUFFIX .header
#define CACHE_DATA_SUFFIX .data
+#define CACHE_VDIR_SUFFIX .vary
+
static char *header_file(apr_pool_t *p, disk_cache_conf *conf,
disk_cache_object_t *dobj, const char *name)
{
@@ -131,8 +134,15 @@
dobj-hashfile = ap_cache_generate_name(p, conf-dirlevels,
conf-dirlength, name);
}
-return apr_pstrcat(p, conf-cache_root, /, dobj-hashfile,
- CACHE_HEADER_SUFFIX, NULL);
+
+if (dobj-prefix) {
+return apr_pstrcat(p, dobj-prefix, CACHE_VDIR_SUFFIX, /,
+ dobj-hashfile, CACHE_HEADER_SUFFIX, NULL);
+ }
+ else {
+return apr_pstrcat(p, conf-cache_root, /, dobj-hashfile,
+ CACHE_HEADER_SUFFIX, NULL);
+ }
}
static char *data_file(apr_pool_t *p, disk_cache_conf *conf,
@@ -142,8 +152,15 @@
dobj-hashfile = ap_cache_generate_name(p, conf-dirlevels,
conf-dirlength, name);
}
-return apr_pstrcat(p, conf-cache_root, /, dobj-hashfile,
- CACHE_DATA_SUFFIX, NULL);
+
+if (dobj-prefix) {
+return apr_pstrcat(p, dobj-prefix, CACHE_VDIR_SUFFIX, /,
+ dobj-hashfile, CACHE_DATA_SUFFIX, NULL);
+ }
+ else {
+return apr_pstrcat(p, conf-cache_root, /, dobj-hashfile,
+ CACHE_DATA_SUFFIX, NULL);
+ }
}
static void mkdir_structure(disk_cache_conf *conf, const char *file,
apr_pool_t *pool)
@@ -352,6 +369,7 @@
obj-key = apr_pstrdup(r-pool, key);
dobj-name = obj-key;
+dobj-prefix = NULL;
dobj-datafile = data_file(r-pool, conf, dobj, key);
dobj-hdrsfile = header_file(r-pool, conf, dobj, key);
dobj-tempfile = apr_pstrcat(r-pool, conf-cache_root, AP_TEMPFILE, NULL);
@@ -393,6 +411,8 @@
info = (obj-info);
/* Open the headers file */
+dobj-prefix = NULL;
+
dobj-hdrsfile = header_file(r-pool, conf, dobj, key);
flags = APR_READ|APR_BINARY|APR_BUFFERED;
rc = apr_file_open(dobj-hfd, dobj-hdrsfile, flags, 0, r-pool);
@@ -428,6 +448,7 @@
nkey = regen_key(r-pool, r-headers_in, varray, key);
dobj-hashfile = NULL;
+dobj-prefix = dobj-hdrsfile;
dobj-hdrsfile = header_file(r-pool, conf, dobj, nkey);
flags = APR_READ|APR_BINARY|APR_BUFFERED;
@@ -784,6 +805,7 @@
dobj-tempfile = apr_pstrcat(r-pool, conf-cache_root,
AP_TEMPFILE, NULL);
tmp = regen_key(r-pool, r-headers_in, varray, dobj-name);
+dobj-prefix = dobj-hdrsfile;
dobj-hashfile = NULL;
dobj-datafile = data_file(r-pool, conf, dobj, tmp);
dobj-hdrsfile = header_file(r-pool, conf, dobj, tmp);
Re: [VOTE] libapreq2-2.06-dev-rc4
Max Kellermann wrote: I did a quick test on FreeBSD, without the perl glue. The build fails with the following message: Making all in module Making all in apache2 make: don't know how to make all-local. Stop *** Error code 1 It turns out that the generated Makefile.in contains: I'll second that... I know it caught me the first time too, and out of habbit I take make instead of gmake. It is however specified in the docs. Maybe Makefile.am should generate a Makefile that checks what make its using if on FreeBSD ? -- END - What doesn't kill us can only make us stronger. Nothing is impossible. Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com http://www.liquidation.com http://www.uksurplus.com http://www.govliquidation.com http://www.gowholesale.com
Re: [PATCH] mod_disk_cache: change handling of varied contents
On 7/20/05 11:25 AM, Paul Querna [EMAIL PROTECTED] wrote: If a URI is varied, all variations will be stored underneath a new hash.header.vary/ directory. Looks good for starters. Good idea. I would like a way to override some varies. For example, in a reverse proxy situation, you may vary on User-Agent header for gzip stuff. However, you really only care whether the user-agent can do gzip or not, you do not want to store a different version for every browser. May be something like this in config: VaryValue User-Agent gzip Where gzip is an environment value set by SetEnv if or something similar. This may have been discussed before.
Re: Initial mod_smtpd code.
On Jul 19, 2005, at 7:39 PM, Jorge Schrauwen wrote: Wouldn't something like VirtualHost www.apache.org:25 ServerName www.apache.org:81 ServerAlias httpd.apache.org internal_dev ServerAdmin [EMAIL PROTECTED] ErrorLog logs/error.log TransferLog logs/access.log SMTP On # like with mod_dav (dav on) /VirtualHost so reusing existing command, then this main an user of www.apache.org lets call him [EMAIL PROTECTED] that the following addresse point to the same. [EMAIL PROTECTED] [EMAIL PROTECTED] this seems to be more logical to me. Personally I think this is too much reuse of configuration in a context that may not make sense to a user or admin. Either way, conf like that is irrelevant to core mod_smtpd. -rian
Re: Apache for win64
At 06:23 AM 7/20/2005, Gopikrishnan Sidhardhan wrote: Tried building it. Went on for some time, with lots of warnings like conversion from size_t to DWORD: possible loss of data. Then the build broke with fatal error LNK1112: module machine type 'AMD64' conflicts with target machine type 'X86'. Any ideas, anyone? Yes - don't try Apache 2.2, try Apache 2.1 alpha and the APR 1.2.0 which isn't quite released yet. Apache 2.0/APR 0.9 haven't been kept up - making them comply with Win64's LP64 model would have broken binary compatibility. Please -do- test Apache 2.1/2.2 candidates as they are announced, since we've done our level best without a Win64 test box to get these compiling clean. Bill
Re: httpd-1.3 patchlets
+1 on both patches; I can see how libhttpd.so gets stripped today.
I'd commit if there were a couple more +1's.
Bill
At 08:16 AM 7/20/2005, Sander Temme wrote:
Two very small patches against 1.3.
First one, make ab default to the highest SSL version available:
Index: src/support/ab.c
===
--- src/support/ab.c(revision 125243)
+++ src/support/ab.c(working copy)
@@ -1655,7 +1655,7 @@
#ifdef USE_SSL
SSL_library_init();
-if (!(ctx = SSL_CTX_new(SSLv2_client_method( {
+if (!(ctx = SSL_CTX_new(SSLv23_client_method( {
fprintf(stderr, Could not init SSL CTX: );
ERR_print_errors_fp(stderr);
exit(1);
Secondly, a patch that keeps --without-execstrip from stripping the
httpd binary:
Index: configure
===
--- configure (revision 219524)
+++ configure (working copy)
@@ -927,6 +927,8 @@
;;
--without-execstrip)
iflags_program=`echo $iflags_program | sed -e 's/-s//'`
+iflags_core=`echo $iflags_core | sed -e 's/-S//' -e 's/
\-S\//'`
+iflags_dso=`echo $iflags_dso | sed -e 's/-S//' -e 's/ \-S\//'`
;;
--suexec-caller=*)
suexec_caller=$apc_optarg
There is a special case for Darwin in configure that makes the httpd
binary get stripped even if --without-execstrip is specified. This
stops that from happening, so --without-execstrip leaves all binaries
unstripped. I think this adheres to the principle of least astonishment.
Let me know if you can fudge that in. (:
Thanks,
S.
--
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: httpd-1.3 patchlets
On Wed, Jul 20, 2005 at 03:16:42PM +0200, Sander Temme wrote:
Two very small patches against 1.3.
First one, make ab default to the highest SSL version available:
Index: src/support/ab.c
===
--- src/support/ab.c(revision 125243)
+++ src/support/ab.c(working copy)
@@ -1655,7 +1655,7 @@
#ifdef USE_SSL
SSL_library_init();
-if (!(ctx = SSL_CTX_new(SSLv2_client_method( {
+if (!(ctx = SSL_CTX_new(SSLv23_client_method( {
fprintf(stderr, Could not init SSL CTX: );
ERR_print_errors_fp(stderr);
exit(1);
+1 from the peanut gallery.
vh
Mads Toftum
--
`Darn it, who spiked my coffee with water?!' - lwall
Memory-Leak problem in own module
Hello, I have written an own Apache-Module for log-rotating. Now my Problem is that I have a memory-Leak and I don't know why. Are there any Debugging-Tools for Apache (or general), where I can see, what memory is allocated and maybe I can see the content of the allocated Memory. For example: After start the Apache the childs are using 20268 kB of Memory. Then I kill the Apache with -USR1 pid, then the childs are using 21872 kB of Memory. So you can see, it grows per reload about 1600 kB of Memory, and I don't know where I have to search. Afters a few days (and reloads) my apache is grown to 200-300MB Memory usage. So if there are any ideas, let me know. Thanks. :) Regards, Timo Eckert
Re: Pondering strings in Apache 3.x
From: William A. Rowe, Jr. What else interests us within an 'ap_string_t' header, that would help eliminate bugs within httpd? A random trailing short following the string, in a 'string debug' mode, to detect buffer overflows? Something similar to detect underflows? Open to all ideas. What are the newer C / C++ compiler standard Safer C Library Functions? Jeff
Re: mod_mbox: js speed and mbox size
From: Bill Stoddard Maxime Petazzoni wrote: As I already said, the AJAX browser in mod_mbox relies on a hidden XmlHttpRequest and on Javascript processing of the replied XML document to generate the message list. Snip Of course, the paging system would solve this problem, too. In addition to this, my Javascript code may not be the most optimized we could find. - Concerning compatibility problems, the whole thing does not work nor with IE, neither with Opera, although both of these browsers does not comply against any javascript error. Any JS compatibility expert in the house ? Heh, you wish :0 This is a cool project, glad it's on the httpd dev list. Bill Hasn't someone been suggesting, for years now, to deaf ears at ASF, for ASF to use the very helpful Windows Scripting (even XmlHttp)? Now ASF's developers and open source developers have discovered XmlHttp! Atlas = Ajax = asp.net 2.0 script callbacks and more http://blogs.msdn.com/nickmalik/archive/2005/07/08/436823.aspx Perhaps (once again): Learn to Script http://www.microsoft.com/technet/scriptcenter/learnit.mspx Jeff
Re: mod_mbox and generate_index
Hi,
I trying to build the standalone helper program generate_index that
the catchup-archive script needs. This program does not seem to be
made by the makefile and the build-dso errors out looking for
lucene4c headers. Any ideas?
Why do you need this program ? If you want to generate the DBMs used
by mod_mbox, it's not generate_index that you need, but
mod-mbox-util. It is compiled by the autotools.
Here's how I compile and setup mod_mbox (yes, I'll be writing a doc on
this later on, eg. at the end of the summer) :
First, make sure you have configured your Apache2 webserver correctly
by adding a config snippet like the following :
LoadModule mbox_module /usr/lib/apache2/modules/mod_mbox.so
AddHandler mbox-handler .mbox
LocationMatch /archives/([^/]+)
MboxIndex On
/LocationMatch
Then, checkout and compile mod_mbox :
% svn co http://svn.apache.org/repos/asf/httpd/mod_mbox/trunk/
% cd trunk/
% ./autogen.sh
% ./configure --with-apxs=/usr/bin/apxs2
[...]
% make clean all
% su
Password:
# make install
# /etc/init.d/apache2 restart
Finally, rsync a mail archive and generate the database :
# mkdir -p /var/www/archives
# cd $_
# rsync -avr svn.apache.org::public-arch/httpd.apache.org/dev/ dev/
# cd dev/
# for i in *.gz ; do gunzip -c $i ${i%*.gz}.mbox ; done
# cp `date +%Y%m` `date +%Y%m`.mbox
# ~/trunk/module-2.0/mod-mbox-util -v -c /var/www/archives/dev
# chown -R www-data:www-data /var/www/archives/
Then, go to http://localhost/archives/dev/
- Sam
--
Maxime Petazzoni (http://www.bulix.org)
-- gone crazy, back soon. leave message.
signature.asc
Description: Digital signature
[STATUS] (httpd-2.1) Wed Jul 20 23:45:47 2005
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2005-06-30 16:42:43 -0400 (Thu, 30 Jun 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 Release history: [NOTE that only Alpha/Beta releases occur in 2.1 development] 2.1.7 : in development 2.1.6 : Released on 6/27/2005 as alpha. 2.1.5 : Tagged on 6/17/2005. 2.1.4 : not released. 2.1.3 : Released on 2/22/2005 as alpha. 2.1.2 : Released on 12/08/2004 as alpha. 2.1.1 : Released on 11/19/2004 as alpha. 2.1.0 : not released. 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
[STATUS] (httpd-2.0) Wed Jul 20 23:45:35 2005
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2005-07-19 17:59:17 -0400 (Tue, 19 Jul 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.55 : in development 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 in STATUS, and then merge into branches/2.0.x. RELEASE SHOWSTOPPERS: * Various fixes to T-E and C-L processing from trunk Refactor mod_proxy_http.c's Transfer-Encoding/Content-Length elections since they didn't follow RFC 2616, in fact didn't seem to make much sense at all. Patch to migrate request-body-handling from trunk/ based on 2.1-dev request body handling behavior (although just a bit more conservative on the side of C-L spooling)... http://people.apache.org/~wrowe/httpd-2.0-proxy-request-3.patch Revert r219061 to properly test this patch, as r219061 masks the underlying bug (although it is a -good- patch in and of itself). +1: wrowe, jim -1: jorton: this is a massive patch and extremely hard to review for actual interesting content; it is mixed in with all sorts of unrelated stuff. It needs to at least be split up or the unrelated stuff removed. unrelated change: s/apr_strnatcasecmp/strcasecmp/ unrelated change: s/b/bb/ on
[STATUS] (httpd-test: perl-framework) Wed Jul 20 23:46:18 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:
Re: Apache for win64
William A. Rowe, Jr. wrote: At 06:23 AM 7/20/2005, Gopikrishnan Sidhardhan wrote: Tried building it. Went on for some time, with lots of warnings like conversion from size_t to DWORD: possible loss of data. Then the build broke with fatal error LNK1112: module machine type 'AMD64' conflicts with target machine type 'X86'. Any ideas, anyone? Yes - don't try Apache 2.2, try Apache 2.1 alpha and the APR 1.2.0 which isn't quite released yet. Apache 2.0/APR 0.9 haven't been kept up - making them comply with Win64's LP64 model would have broken binary compatibility. Please -do- test Apache 2.1/2.2 candidates as they are announced, since we've done our level best without a Win64 test box to get these compiling clean. Bill If you can point me to the 2.1/2.2 source I can try building it and let you know what happens. Thanks, --Gopi
Re: Apache for win64
William A. Rowe, Jr. wrote: At 06:23 AM 7/20/2005, Gopikrishnan Sidhardhan wrote: Tried building it. Went on for some time, with lots of warnings like conversion from size_t to DWORD: possible loss of data. Then the build broke with fatal error LNK1112: module machine type 'AMD64' conflicts with target machine type 'X86'. Any ideas, anyone? Yes - don't try Apache 2.2, try Apache 2.1 alpha and the APR 1.2.0 which isn't quite released yet. You do mean don't try Apache 2.0, right? Thanks, --Gopi Apache 2.0/APR 0.9 haven't been kept up - making them comply with Win64's LP64 model would have broken binary compatibility. Please -do- test Apache 2.1/2.2 candidates as they are announced, since we've done our level best without a Win64 test box to get these compiling clean. Bill
