LZMA tar balls ?
hi. I've noticed that some tar balls are getting created using the lzma format as a download option (ftp.gnu.org and Imagemagik being the latest two I've noticed) with the file size being significantly smaller than bz2. I just did a very scientific benchmark on compression tools (that is ran them once on a single fileset), and noticed that with the latest httpd tar ball I can achieve a 1M reduction in filesize (~20%) when using lzma. the only downside about using lzma is that it is S*L*O*W to compress files (seems fast enough in decompression though) The lzma format is supported in the latest version of gnutar (1.21) as an option 'J' and there are windows versions of it out there as well, but it is not a standard package in most distributions yet. anyway.. I thought I'd start a thread about it. 20% savings seemed pretty big to me. Regards Ian
Re: svn commit: r693697 - in /httpd/sandbox/mod_valid_utf8: ./ README mod_valid_utf8.c
Thanks for the feedback.
I'll fix the code soon.
Nick Kew wrote:
On Wed, 10 Sep 2008 03:54:00 -
[EMAIL PROTECTED] wrote:
Author: ianh
Date: Tue Sep 9 20:53:59 2008
New Revision: 693697
URL: http://svn.apache.org/viewvc?rev=693697view=rev
Log:
initial check in.
this filter validates that the incoming request contains valid UTF8
characters.
Why?
Last time I looked, incoming charsets were indeed a problem area,
but a browser submitting an HTML form would de-facto use the
same charset as the form. Not necessarily utf-8.
Not to mention the many other use cases for sending non-utf8 data.
+static char* validate_buffer( apr_pool_t *p, const char* inbuf,
apr_size_t* length) +{
Looks like a potential util_ function. Cousin to both apr_uri
and apr_xlate.
+if (inbuf[i] == '%' ) {
+if ((i len -2 ) ishexnumber( inbuf[i+1])
ishexnumber( inbuf[i+2])) {
... is all very well, but
+else {
+buffer[j++]=inbuf[i++];
+}
Shouldn't that at least be marked /* FIXME */
where you potentially let through the chars you're
supposed to block ?
+ap_hook_pre_connection(utf8_pre_conn, NULL, NULL,
APR_HOOK_MIDDLE); +
+ap_register_input_filter(utf8_filter_name, utf8_in_filter, NULL,
+ AP_FTYPE_NETWORK - 1);
Huh? Isn't that before mod_ssl, let alone mod_deflate, mod_charset?
And no excape path for binary data either. It'll cripple any server
with it loaded!
Re: Better mod_unique_id
Hi Konstantin.
I'm about to look at the same issue for my employer.
for my version I was planning on using apr_uuid_get that uses
uuid_create / uuid_generate function to generate a unique value.
have you looked at this function?
regards
Ian
Konstantin Chuguev wrote:
Hi,
I'm developing a solution generating unique IDs for the requests to
websites that are not only clustered but also geographically
dispersed. This implies the following:
- the website's virtual host section on each Apache server has the
same ServerName which is mapped by DNS to different IP addresses using
various methods, geo-proximity, round-robin, etc.
- the virtual host's IP address is normally but not necessarily *;
- the actual IP address the Apache listens to for this virtual host is
normally, but not necessarily, an intranet address (behind a load
balancer).
After analysing the format of the ID generated by mod_unique_id, and
reading the module's source code, I have a feeling that this module
has serious flaws if used in my situation.
No offence to the authors, I'm sure the module serves its purpose just
right for the majority of its users. But as it seems that it doesn't
do this in my case, I thought I'd better ask if someone knows why.
I understand that the module is relatively old and likely has been
ported from a pre-2.0 version, when no APR library existed, and this
might explain its design. I'd be glad if someone could either confirm
this or
explain why it has been done like that.
Now to the point of my question. The unique_id_rec structure that
contains the binary representation of the unique ID consists of the
following fields:
unsigned int stamp;
unsigned int in_addr;
unsigned int pid;
unsigned short counter;
unsigned int thread_index;
1. Why use unsigned int timestamp when there exists apr_time_t which
is 64 bit and seems to be at least 1 microsecond accurate? Surely
there is unsigned short counter which helps if there is more than one
request coming to the same IP address / PID / thread per second, but
still I can hardly see this as a better design.
2. Why use unsigned id pid plus unsigned int thread_index if there
exists long r-connection-id? thread_index is in fact produced by
doing htonl((unsigned int)r-connection-id), but MPMs seem to ensure
the child_id is included there already! While it is just 4 bytes long
compared to the 8-byte pid/thread_index combination, still it is
guaranteed to be unique among all worker threads of the Apache server
in the system. And I don't think this particular field needs
converting to the network byte order.
3. Using unsigned int in_addr with the server-side IPv4 address works
well in the single cluster in the IPv4 network only. What if only IPv6
is being used in the intranet? What if multiple dispersed clusters
with exactly the same intranet IP addressing schemes serve the same
website? Please correct me if I'm wrong but I think the following
structure would represent the unique website more correctly:
- union {struct in_addr, struct in6_addr} local_ip_addr: the IP
address of the local side of the HTTP connection;
- union {struct in_addr, struct in6_addr} dns_ip_addr: one (any?) of
the IP addresses that are mapped to the website's domain name in DNS.
The latter can be omitted if the former IP address is public.
Does anyone see any flaws in the design where the following structure
is used?
apr_time_t stamp;// 8 bytes, converted to network byte order
long connection_id;// size depends on architecture: normally 4
or 8 bytes, doesn't need htonl
union {struct in_addr, struct in6_addr} local_ip_addr;// 4 to
16 bytes
[union {struct in_addr, struct in6_addr} dns_ip_addr;]// 0 to
16 bytes
Comments and suggestions are appreciated.
Konstantin Chuguev
Software Developer
Clickstream Technologies PLC, 58 Davies Street, London, W1K 5JF,
Registered in England No. 3774129
Re: Apache 3.0
Paul Querna wrote: For those who were not there, slides from Roy's keynote at ApacheCon EU: http://roy.gbiv.com/talks/200804_Apache3_ApacheCon.pdf I've got a couple of naive questions about 3. My apologies.. but i'm only looking at the slides, not the speech itself. What will the role of apache 3 be. on slides 10 thru 13 you show the history and it's uses, I'm just wondering if you have any dreams on how this will make the internet a better place to be. Or are you intending 3.0 to be more of a consolidation/simplification of the codebase to base new ideas on? you mention 'adult serfs' in the slide, but you don't really go into it.. how are these going to change my life. (my life being as a sysadmin/module developer/reverse proxy user) if v3 will be waka only, what will happen to POP3, FTP and the other protocol support? waka .. would i be wrong in saying that waka is a compressed version of http 1.x ? what other things does it give me (a application developer or a browser) that http doesn't give. Is the main aim to reduce the size of the header, if so what have you done about cookies/state passing, which take up most of the space on some domains. have you got one of the browser groups onboard to write something that talks waka? is waka stateless? multi-language support. are you planning on integrating multiple language support into it from the onset? It looks like a cool idea, i'm still trying to wrap my head around how I would use it to make my system design better than what I have today, but I did the same thing when I first heard about 2.0 regards Ian -Paul
Re: Integrity of Apache source code
While open source is fantastic, and provides highly visible means. It can still be hacked. I can describe what has happened in this case: 1. joe hacker hacks one of the 'open source groups' machines. at this point he is assumed to have access to the source code repository. 2. assume he figures out how to change the source code in the repository in some weird way, or then modifies the tarball. a. he modifies the tarball and inserts some trojan. at this point in time people will be downloading the trojan, and it will start infecting people who are lazy. The non-lazy people (and there are people out there who do this) will check the MD5 GPG-Key of the tarball, and will verify that the code matches the signatures. when it doesn't they complain VERY LOUDLY. They even complain when the GPG key is not signed with enough people who have enough trust. so as long as you and your employer always verify with the GPG-key of the tarball that it is signed correctly, then this is not such a big issue. b. he modifies the source code in the repository directly and in a manner that doesn't generate an email/commit message. when something like this occurs ( I'm not even sure if it is possible in SVN, but I think it was in CVS) then the next time one of the core developers update their version of the code they will see the code has been changed. It is then up to the developer to review the change or the file being changed and to see what has happened. Our developers are alert, and most will question what is going on... but it is a risk. regards Ian Jim Jagielski wrote: On Dec 17, 2007, at 6:22 PM, Andrew Beverley wrote: Hi, I hope that this is the correct mailing list for this question, and that you can easily provide a quick response. I am currently working within the UK Ministry of Defence, and am trying to get Apache web server accredited as software able to be installed on one of our defence networks. However, one of the barriers I am coming up against is the argument that, because it is open source, that someone could contribute a Trojan horse to the code and that the code could be included in the official product. What I would like to know, so that I can dispel this, is what procedures are in place to prevent this happening? I know that all downloads are digitally signed, but what other procedures are in place? For example, how is code signed-off for inclusion in production releases? I am going to a meeting about this very shortly so would appreciate a prompt response! In one word visibility. Since all development is done in the open, and since all code is vetted by at least 3 committers on the project and all commits are viewable via subversion, the risk associated with this is pretty pretty small.
Re: Proxying subrequests
Akins, Brian wrote: -1 from me (if that counts.) Using ProxyPass should be fine for 95% of the use cases?? ProxyPass /cnn http://www.cnn.com/ !--#include virtual=/cnn/WORLD/index.html -- yes. if you: a. have a static small number of hosts b. those hosts don't change often if either of these 2 conditions aren't met, then proxypass is next to useless.
Re: Proxying subrequests
Nick Kew wrote: Our subrequest API currently handles only local subrequests, so for example mod_include doesn't support !--#include virtual=http://example.com/example.txt--. I've worked around this in the past with some ugly hacks. Looking at the code, it's actually very simple to build in support for remote URLs into the subrequest mechanism using mod_proxy. I've just test-driven a patch comprising just six lines of code (attached), and it works. The patch still needs attention to escaping, but before I deal with that, can I ask for votes on the concept? Is there any reason not to add this feature? +1 I've wanted this feature in mod-include for years, and have been too lazy to do it. (relying on custom module hacks to implement it) as for PHP security holes.. maybe a config option or something to enable/disable it.
Re: svn commit: r569204 - in /httpd/httpd/trunk/modules/experimental: config.m4 mod_rewrite_filter.c mod_sedfilter.c
Ruediger Pluem wrote: On 08/24/2007 05:30 AM, William A. Rowe, Jr. wrote: Roy T. Fielding wrote: On Aug 23, 2007, at 7:21 PM, William A. Rowe, Jr. wrote: Joshua Slive wrote: On 8/23/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I changed it, I'll be happy (urp) to change it again [ ] mod_pcre_filter [ ] mod_text_filter [*] mod_subst_filter [ ] mod_rewrite_filter or [*] mod_substitute or [*] mod_regex_replace, or ... [*] mod_substitute I'm the same as Ruediger, but would also suggest mod_replace. regards Ian Regards Rüdiger
OS/X + Cisco VPN == trouble
Hi. This one is frustrating me to no end, and was wondering if some BSD/OSX guru can help me out a bit. I'm using the trunk, and trying to start apache, but I keep getting a lock/sem problem [Fri Aug 24 10:51:53 2007] [emerg] (28)No space left on device: Couldn't create accept lock this only happens if I have run the VPN. when I reboot it works great (until I check into the VPN). from what I can see this error is usually caused by running out of sempahores, but ipcs doesn't show any. and to make matters worse, it only started happening about 2 weeks ago. regards Ian
Re: OS/X + Cisco VPN == trouble
Graham Dumpleton wrote: On 24/08/07, Ian Holsman [EMAIL PROTECTED] wrote: Hi. This one is frustrating me to no end, and was wondering if some BSD/OSX guru can help me out a bit. I'm using the trunk, and trying to start apache, but I keep getting a lock/sem problem [Fri Aug 24 10:51:53 2007] [emerg] (28)No space left on device: Couldn't create accept lock this only happens if I have run the VPN. when I reboot it works great (until I check into the VPN). from what I can see this error is usually caused by running out of sempahores, but ipcs doesn't show any. and to make matters worse, it only started happening about 2 weeks ago. As a workaround while you resolve why you are running out of mutexes and/or how to increase the number, use AcceptMutex directive to have it use a different mutex mechanism. http://httpd.apache.org/docs/2.2/mod/mpm_common.html#acceptmutex This question was perhaps more appropriate for user list and not developers list. Graham Thanks Graham, I'll remember the users list in the future. as I was using the trunk, I thought it might have been a recent patch to apr/httpd which has caused it, thats all. BTW.. the acceptmutex works for stock apache, but not for mod_python which doesn't have the ability to change the mutex mechanism it uses.
[ANN] mod_concat
I’ve just created a new module which implements one of Brad’s features of perlbal -- http://www.danga.com/perlbal/ http://www.danga.com/perlbal/. The ability to concatenate CSS or javascript files into a single HTTP request. the request will look like: http://hostname/cdn/??music2.js,mp.js,dir1/dalai_llama.js,ratings_widget.js,widget_config.js,common.js my initial testing shows a performance gain of about 1 second when I request a file from the other side of the pacific ocean (melbourne to dallas TX) you can try it out yourself: http://lime.holsman.net:8001/concat/with.html - CSS/JS using concat and http://lime.holsman.net:8001/concat/without.html -- using standard method the code lives here: http://code.google.com/p/modconcat/
Re: mod_atom
Tim Bray wrote: On Jun 27, 2007, at 12:44 AM, Paul Querna wrote: As it is currently written, I don't think it makes too much sense to put it into httpd -- but if we could work on abstracting down a core, and a set of separate hooks for storage + maybe a way to easily build end user display, I think it would be a very cool thing to include. We'll have to think about that. The whole point of APP is so dumb clients like cellphones and blog-authoring packages can push bits at a server and leave the server in control of where things go. I'm trying to imagine what the storage hooks might look like. As for end-user display, I doubt it; there are all sorts of excellent blogging publishing engines out there that take care of that for you and httpd doesn't need to compete with. APP mod_atom are narrowly focused at the problem of resource CRUD. If I am understand Paul correctly, what Paul is meaning on the storage side is so I can add a module to say: I want these things stored on a file system or add a different one I want these in a database and possibly have a 3rd party developer decide. This is really cool. I want the data to reside in Bigtable this decision would be hidden from the user. just as it is hidden from the user in the SVN client at the moment. Regards Ian
Re: [Fwd: Apache httpd vulenrabilities]
Hey Bill just to clarify these are LOCAL DoS attacks? ie you need access to the machine (or the ability to execute php) in order for this to be an issue? William A. Rowe, Jr. wrote: Published - ergo moving discussion from security@ to [EMAIL PROTECTED] Of course if in the course of this discussion, you uncover a new edge case, feel free to move that thread back to [EMAIL PROTECTED] to discuss your new discovery. Subject: Apache httpd vulenrabilities From: Blazej Miga [EMAIL PROTECTED] Date: Tue, 29 May 2007 20:00:42 +0200 (CEST) To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] PSNC Security Team has got the pleasure to announce that, as a result of Apache httpd server (ver. 1.3.x, 2.0.x and 2.2.x) source code analysis, several vulnerabilities have been found that make it possible to perfom a DoS attack against the services and the system that the application is running on. Below the basic information on found vulnerabilities may be found: Vuln#1 Httpd Server DoS Test environment: ver. 2.0.59, 2.2.4, prefork mpm module An appropriate code run in the worker process context makes it possible to kill all worker processes with simultaneous blocking of creating new worker processes by the master process. As a result, the server stops to accept and handle new connections. Vuln #2 SIGUSR1 killer Test environment: ver. 2.0.59, 2.2.4 prefork mpm module An appropriate code run in the worker process context makes it possible to send SIGUSR1 signals by the master process (that runs with root credentials) to an arbitrary process within the system. Vuln #3 SIGUSR1 killer Test environment: ver 1.3.37 An appropriate code run in the worker process context makes it possible to send SIGUSR1 signals by the master process (that runs with root credentials) to an arbitrary process within the system. Vuln #4 System DoS Test environment: ver 2.0.59, 2.2.4 prefork mpm module An appropriate code run in the worker process context makes it possible to force the master process to create an unlimited amount of new worker processes. As a result, the activity of the whole system may be blocked. Countermeasures: Disabling the possibility of running the user.s code in the worker process context. An especial emphasis should be put on programming languages that may be configures as an Apache module (like mod_php, mod_perl etc.) in order to block dangerous functions, e.g. dl(), dlopen(). The information on the vulnerabilities above was sent to Apache Software Foundation on 16 May, 2006. For over 1 year no official patch has been issued. PSNC Security Team is currently working on its own, unofficial patches. Our patches will be published on 18 June, 2007 on the team webpage (http://security.psnc.pl). On 20 June, 2007 the detailed information on the found vulnerabilities will be issued. PSNC Security Team
Re: Question about httpd / APR version relationship
Guenter Knauf wrote: Hi, On 5/9/07, Guenter Knauf [EMAIL PROTECTED] wrote: Apache 2.0.x - has to use APR 0.9.x Apache 2.2.x - has to use APR 1.2.x Apache 2.3.x - has to use APR 1.3.x is this now a mandatory relationship, or is it valid to: build Apache 2.2.x with APR 1.3.x This would likely work, but I wouldn't recommend it for official builds. You wouldn't want module authors to start depending on new functionality in APR 1.3.x when most versions of Apache 2.2.x don't have that. build Apache 2.3.x with APR 1.2.x That /might/ work, unless Apache is depending on new functionality in APR 1.3.x, which it very well might be. One of those YMMV, if it breaks you get to keep both pieces kind of situations. ok, that's exactly what I thought too - thanks for confirming So how about the future? Will this relationship continue? there is no guarantee of this. APR might slow down it's development and 2.4 might ship with APR 1.3. it really depends on what new versions of httpd require from the portability layer. regards Ian thanks, Guenter.
Re: Question on multi-process CGID
tackling this another way. how hard would it be to use something like mod_fastcgi of instead of the standard CGI interface? On 21/06/2006, at 8:00 AM, Paul Querna wrote: Mendonce, Kiran (STSD) wrote: We tried using mod_cgi with worker. And its very slow. So that's not an option we have. Currently we have only worker MPM supported on HP-UX which is why I tried the multiple cgid approach. Ah. Now it makes sense. My experiences with this have only been on Linux, FreeBSD and Solaris. It is very much a possibility that fork() on HP-UX really sucks. And the solution that was discussed then was also to provide multiple CGI daemons. Will this be a feature that will be available sometime ? I don't think anyone is currently working on it. Feel Free to post patches :) Also, I'd like to know if any benchmaking results for CGI has been published with comparisons between the different Apache MPMs. Never done it on HP-UX. On Linux 2.6 the experimental Event MPM is fastest, then the Worker MPM and then the Prefork MPM. -Paul
Re: flood: enhancement - random string substitution in URL
Hi Guy.
unified diff format is preferred. you can email it to the list, or
put it in a bug (or both)
I'm not sure, but I think flood is maintained on a different list..
(it's been a while)
--Ian
On 05/10/2006, at 10:24 AM, Guy Ferraiolo wrote:
Folks
I've developed some additional functionality for flood: random text
substitution in the URL. It has been in use here for several
years. I
think this is a very useful addition and I'd like to see it become
part
of flood.
The feature works in this way: the URL contains a string of the form
'${subst_var}'. On each generation of a URL, that entire string is
replaced by a line randomly chosen from the so-called substitution
file.
This file consists of Unix text delimited by newlines. The
substitution
file is paired with the substitution variable (in this case subst_var)
via a subst_list xml construct in the flood config file. An arbitrary
number of variable - file pairings can be defined in the config file.
Additionally, this functionality can substitute text in all or part of
the POST payload. In that case the metasymbol '\r' will be
replaced by
newline (\012).
3 things are necessary for the feature to work:
1. You must use a 'requesttemplate' to hold your URL
2. You must supply a 'subst_list' xml construct in your flood
config file.
3. You must supply a 'substitution file' containing the lines that
will be randomly substituted.
I can provide much more documentation about the feature and advice on
its effective use.
A patch is ready, including a revised version of flood.dtd.
How can I submit this?
Guy
PS - The original flood.dtd does not serve to validate because it
contains the line:
?xml version=1.0 ?. That problem has been fixed. There is
also no
mention of the 'configversion' attribute which the code expects. That
has not been fixed.
--
Guy Ferraiolo mailto:[EMAIL PROTECTED]
Performance Measurement Analysis http://CNET.com
CNETtel:
1.908.541.3739
1200 Route 22 East fax: 1.908.575.7474
Bridgewater, NJ 08807 cel: 1.732.618.0250
Ian Holsman
[EMAIL PROTECTED]
http://parent-chatter.com -- what do parents know?
Re: Memory usage in apache
Thanks I'll see if I can apply those to mod_python. regards Ian On 23/08/2006, at 2:27 AM, Joost de Heer wrote: Joost de Heer schreef: Once you load something like mod_python or mod_perl, it's not really Apache memory that's your problem. Philippe Chiasson gave a really interesting talk at ApacheCon Europe about memory management for mod_perl. His slides are online somewhere, but I can't find the URL right now. Perhaps someone else has them? I just realised I had the URL on my work computer. Here it is: http://gozer.ectoplasm.org/Talks/talks.html (Talk is 'mod_perl for speed freaks!') -- Ian Holsman [EMAIL PROTECTED] http://car-chatter.com/ where car fanatics meet
Re: [Patch]: Do not compress bodies of header only requests in mod_deflate
personally I think GET HEAD processing should be identical until
the very last moment.
this avoids bugs creeping in which process the body for some reason
and add a header after mod_deflate is run
(I can't think of any which do this BTW)
are you seeing a problem somewhere Ruediger?
regards
Ian
On 18/07/2006, at 3:28 AM, Ruediger Pluem wrote:
The following patch avoids that the deflate output filter wastes
cycles in
compressing the body of a header only request that gets thrown away
by http
header filter afterwards anyway.
OTH a HEAD and a GET request differ regarding regarding the T-E and
C-L headers
(everything else is the same). So I am not sure if this patch
breaks RFC2616.
Comments?
Index: modules/filters/mod_deflate.c
===
--- modules/filters/mod_deflate.c (Revision 422739)
+++ modules/filters/mod_deflate.c (Arbeitskopie)
@@ -397,8 +397,6 @@
/* We're cool with filtering this. */
ctx = f-ctx = apr_pcalloc(r-pool, sizeof(*ctx));
-ctx-bb = apr_brigade_create(r-pool, f-c-bucket_alloc);
-ctx-buffer = apr_palloc(r-pool, c-bufferSize);
zRC = deflateInit2(ctx-stream, c-compressionlevel,
Z_DEFLATED,
c-windowSize, c-memlevel,
@@ -418,11 +416,6 @@
return ap_pass_brigade(f-next, bb);
}
-/* add immortal gzip header */
-e = apr_bucket_immortal_create(gzip_header, sizeof
gzip_header,
- f-c-bucket_alloc);
-APR_BRIGADE_INSERT_TAIL(ctx-bb, e);
-
/* If the entire Content-Encoding is identity, we can
replace it. */
if (!encoding || !strcasecmp(encoding, identity)) {
apr_table_setn(r-headers_out, Content-Encoding,
gzip);
@@ -432,6 +425,24 @@
}
apr_table_unset(r-headers_out, Content-Length);
+/*
+ * Do not waste cycles on compressing bodys of header only
requests as
+ * the body data is dumped later anyway.
+ */
+if (r-header_only) {
+deflateEnd(ctx-stream);
+ap_remove_output_filter(f);
+
+}
+
+ctx-bb = apr_brigade_create(r-pool, f-c-bucket_alloc);
+ctx-buffer = apr_palloc(r-pool, c-bufferSize);
+
+/* add immortal gzip header */
+e = apr_bucket_immortal_create(gzip_header, sizeof
gzip_header,
+ f-c-bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(ctx-bb, e);
+
/* initialize deflate output buffer */
ctx-stream.next_out = ctx-buffer;
ctx-stream.avail_out = c-bufferSize;
return ap_pass_brigade(f-next, bb);
Regards
Rüdiger
Index: modules/filters/mod_deflate.c
===
--- modules/filters/mod_deflate.c (Revision 422739)
+++ modules/filters/mod_deflate.c (Arbeitskopie)
@@ -397,8 +397,6 @@
/* We're cool with filtering this. */
ctx = f-ctx = apr_pcalloc(r-pool, sizeof(*ctx));
-ctx-bb = apr_brigade_create(r-pool, f-c-bucket_alloc);
-ctx-buffer = apr_palloc(r-pool, c-bufferSize);
zRC = deflateInit2(ctx-stream, c-compressionlevel,
Z_DEFLATED,
c-windowSize, c-memlevel,
@@ -418,11 +416,6 @@
return ap_pass_brigade(f-next, bb);
}
-/* add immortal gzip header */
-e = apr_bucket_immortal_create(gzip_header, sizeof
gzip_header,
- f-c-bucket_alloc);
-APR_BRIGADE_INSERT_TAIL(ctx-bb, e);
-
/* If the entire Content-Encoding is identity, we can
replace it. */
if (!encoding || !strcasecmp(encoding, identity)) {
apr_table_setn(r-headers_out, Content-Encoding,
gzip);
@@ -432,6 +425,24 @@
}
apr_table_unset(r-headers_out, Content-Length);
+/*
+ * Do not waste cycles on compressing bodys of header only
requests as
+ * the body data is dumped later anyway.
+ */
+if (r-header_only) {
+deflateEnd(ctx-stream);
+ap_remove_output_filter(f);
+return ap_pass_brigade(f-next, bb);
+}
+
+ctx-bb = apr_brigade_create(r-pool, f-c-bucket_alloc);
+ctx-buffer = apr_palloc(r-pool, c-bufferSize);
+
+/* add immortal gzip header */
+e = apr_bucket_immortal_create(gzip_header, sizeof
gzip_header,
+ f-c-bucket_alloc);
+APR_BRIGADE_INSERT_TAIL(ctx-bb, e);
+
/* initialize deflate output buffer */
ctx-stream.next_out = ctx-buffer;
ctx-stream.avail_out = c-bufferSize;
Re: [Patch]: Do not compress bodies of header only requests in mod_deflate
On 18/07/2006, at 8:06 AM, Ruediger Pluem wrote: (I can't think of any which do this BTW) are you seeing a problem somewhere Ruediger? The biggest problem at the moment is that I fear that I do not get your point correctly :-). So some explanations from your side would be very helpful to get myself on the correct track. the question i'm asking is why bother. how many HEADs would a typical site get? I'd imagine about 1%. and i'm also guessing that most of these would be from robots (who don't care about response time) so this patch will have little or no impact on resource utilization on the machine itself. Is this a DoS threat your trying to avoid? I think there are easier ways to DoS a httpd server, so it's not this so my question again are you seeing a problem? because if there isn't a problem all you are doing is adding another code path and potential entry point for bugs. Thanks and regards Rüdiger
Re: [PATCH] Compilation on Solaris
huh? why is the licensing terms stopping us recommending something? we recommend VC2005 for windows and that it commercial, I don't see the difference. (and yes.. I saw mads's comment that this studio is free if your register) On 17/06/2006, at 4:56 AM, Justin Erenkrantz wrote: On 6/16/06, Shanti Subramanyam [EMAIL PROTECTED] wrote: Here is the patch : --- README.platformsFri Jun 16 09:12:33 2006 +++ README.platforms.orig Thu Jun 15 13:13:50 2006 @@ -95,12 +95,4 @@ http://www.apache.org/dist/httpd/patches/apply_to_2.0.49/ aix_xlc_optimization.patch (That patch works with many recent levels of Apache 2+.) - - Solaris: -On Solaris, much better performance can be achieved by using the Sun Studio compiler -instead of gcc. Download the compiler from - -http://www.opensolaris.org/os/community/tools/sun_studio_tools/ - -Use the following compiler flags: -XO4 -xchip=generic Actually, if I read the license, I'm not sure this is a great idea to recommend now: http://www.opensolaris.org/os/community/tools/sun_studio_tools/sssent/ Specifically, it says: --- Permitted Use: Provided that You are a participant of the OpenSolaris community, You may use the software for Research and Instructional, Individual, and Commercial Use to design, develop, test, or otherwise engineer software. --- In the loosest terms, that *might* be true. But, I'm not quite so sure. Roy? -- justin
Re: Email address on mail archive (fwd)
On 29/04/2006, at 4:30 AM, Justin Erenkrantz wrote: Welcome to the big bad Internet. Not everyone is nice. It's a valuable lesson to learn. We can do all of the obfuscation we want in mod_mbox, but spambots *do* just subscribe to the lists. (We see them in the subscriber lists.) So, we can't obfuscate those addresses in the emails everyone receives. -- justin Justin. we *want* people to use our bug system and our mailing lists. Some of the subscribers may not be as experienced as you. They are just after a certain level of comfort. By obfuscating their email address on web pages and bug reports we give the comfort to them, and they in turn feel more comfortable posting. It doesn't matter if we don't stop *all* bots, what is being asked for is the status quo. The status quo on nearly all web-based products is to hide the email address. and actually I think you could design the mailing list software *to* obsfucate personal email addresses (similar to what gmane does). It is just that the status quo isn't there yet for mailing lists. --Ian -- Ian Holsman Ian_at_Holsman.NET Never forget that you are unique, like everyone else.
Re: RFC: make selecting virtual host a hook
This sounds like a good idea. are you thinking of it being a config-time hook or a additional hook in the request-processing stage? I can see cases where you might want both. regards Ian On 27/04/2006, at 11:54 PM, Brian Akins wrote: As most things are now in hooks, why not make virtual host selection a hook as well? I have a few really strange setups that would be alot easier to configure if I could override how the virtual host is selected. Thoughts? -- Brian Akins Lead Systems Engineer CNN Internet Technologies -- Ian Holsman ++61-3-9818-0132 in this place it takes all the running you can do, to keep in the same place. - Lewis Caroll
Re: mod_deflate patch
+1 from me.
On 19/04/2006, at 4:37 AM, Brian J. France wrote:
This was talked about a few weeks back but I don't think anything
ever came of it. The patch below would allow mod_deflate to
compress internal redirects while still skipping sub requests.
I have been running this on my personal server for a few weeks now
with no issues.
Let the voting begin.
Brian
Index: modules/filters/mod_deflate.c
===
--- modules/filters/mod_deflate.c (revision 394996)
+++ modules/filters/mod_deflate.c (working copy)
@@ -240,7 +240,7 @@
const char *encoding;
/* only work on main request/no subrequests */
-if (!ap_is_initial_req(r)) {
+if (r-main != NULL) {
ap_remove_output_filter(f);
return ap_pass_brigade(f-next, bb);
}
--
Ian Holsman
Zilbo.com / (425) 296-6771 USA/ ++61 (03) 9818-0132 Australia
You miss 100% of the shots you don't take -- Wayne Gretzky
Re: Summer of Code 2006 -- a link
Be careful when it comes to scoping work. I found last year that some students last year will do what is asked for, not more. On 19/04/2006, at 9:59 AM, Justin Erenkrantz wrote: On 4/18/06, Ian Holsman [EMAIL PROTECTED] wrote: it sounds like we have got some pretty good ideas so far. the next step is to put them on the Wiki Page (or create a 2nd wiki page just for httpd and APR projects to reduce the clutter the URL is here: http://wiki.apache.org/general/SummerOfCode2006 I've posted one of my ideas to that wiki page: creating a set of test cases for mod_cache. That'd be really really nice to have and has the 'right'-ish scope. If they breeze through those, they can create proxy tests. ;-) -- justin -- Ian Holsman ++61-3-9818-0132 If everything seems under control, you're not going fast enough. - Mario Andretti
It's that time of the year again
Google is about to start it's summer of code project what does this mean for HTTP/APR ? we need: - mentors and - project ideas. so.. if there is any niggly things or cool projects you haven't got the time to do yourself, but could devote 2-3 hrs/week to help someone else do, and could be accomplished by a good student in 10-12wks. now's the time. ideas so far (half joking): - mod_ircd - implementing a UDP protocol - a caching module implement CML (cache-meta-language) - a SEDA type MPM last year's SoC produced: - mod_smtpd - mod_mbox enhancements - mod_cache_requestor (which i don't think really took off) and 2 active comitters. so.. lets get brainstorming. Let's see HTTP get the prize for most ideas (and beat those java weanies) --Ian -- Ian Holsman ++61-3-9877-0909 in this place it takes all the running you can do, to keep in the same place. - Lewis Caroll
Re: It's that time of the year again
yeah.. thats the hard part of SoC. not coding it yourself in 20 minutes, and leaving it for your student to do ;-) On 18/04/2006, at 5:43 AM, Brian Akins wrote: Parin Shah wrote: I have liked the idea of mod_memcached. I can work on it with you (if we have Soc student for this project, I can work with him as well ) To clarify, I really meant to say mod_memcache, the client part, not the server. Was just an idea, I can help in some way as well. I have a working prototype now. -- Brian Akins Lead Systems Engineer CNN Internet Technologies -- Ian Holsman ++61-3-9818-0132 Good judgment comes from experience, experience comes from bad judgment.
Re: mod_cache_shared?
My only thoughts is that if you could integrate with ICP (which squid uses) it might make it easier to get mod_cache_shared installed, tested, and used in large organizations who already use a caching solution. That way they could put a single mod_cache_shared into their existing pool and see how it works/compares to squid, and then slowly move their existing base to mod_cache_shared if it is better. Inventing yet another protocol is not going to help people switch over. (and it is bound to get complex quickly as all the boundary cases get added into the protocol) regards Ian (same thing can be applied to HTCP or CARP.. I'm protocol agnostic when it comes to choosing, but -0.5 on inventing another one) Paul Querna wrote: I have been thinking about some ideas for allowing multiple mod_disk_cache instances to share their cache. There are existing 'solutions' to 'this' problem: - HTCP, RFC 2756, http://www.htcp.org/ - ICP, RFC 2186 and RFC 2187, http://icp.ircache.net/ - CARP, http://icp.ircache.net/carp.txt I've only done a quick look at each, and they all seem to be overly complicated. If anyone has experience with these or other methods, please speak up :) HTCP seems like the best pre-designed solution at this time. It doesn't look like it got much adoption from any other proxy/cache servers. Anyone know why? But, the 'lets do this quickly and make it work' part of me says, we can design something very simple and 'stupid', that uses the knowledge of how mod_cache works. What we would do is create a new mod_cache backend, 'mod_cache_shared'. It would run in the Quick Handler, after the other cache methods. This mod_cache_shared would use some communication protocol to request this document from its peers. If no peer replied in 5 ms, we would DECLINE the quick handler, and continue on the normal path of a cache miss. Of course, giving-up timeout would be configurable. If a peer replied with 'yes we have this', we would fetch it from there, and *also* insert the required output filters, to add it to our local cache. Thoughts? -Paul
Re: how does this get changed?
maybe if mod_access_compat is included by default statically into httpd itself? (unless explicitly disabled) we could make it optional in 2.6 (and remove docs on it), and remove in 2.8 or something. this will give people plenty of time to switch over. David Reid wrote: Joshua Slive wrote: On 2/16/06, David Reid [EMAIL PROTECTED] wrote: Rather than try and piece it together, can someone simply answer this simple question? Maybe then this mail and your reply will help other poor souls trying to make the change. Convert this Order deny,allow Deny from all Require all denied But David, you should really just be including mod_access_compat. I think there are plenty of people here who are going to vote against any release of 2.4 unless configurations like the one above work out of the box with mod_access_compat included. So if you are having problems, it is better to identify them now. I have been using the compat module (which actually worked this time) but I've run into a SIGBUS or SIGILL (latter if not debug build) using the module. Also, unless there is an upgrade path that make sense, is well documented and tested the new auth stuff might as well never have been added. The last set of auth changes left a bad taste in a lot of peoples mouths - shall we try and avoid that this time round? david
Re: Change in how to configure authorization
Hi Joshua: httpd.conf.in has the new structure httpd-std.conf (the one I was looking at) didn't ;( regards
Change in how to configure authorization
Hi. It looks like recently some people have changed how authorization is working on the trunk. Could those people please 1. add a note to docs/upgrading.html to document what us idiots need to do to get our config to work again? 2. change httpd-std.conf so it doesn't reference the depcreated stuff 3. fix core.html.en so it has the 'satisfy' directive (my version doesn't) a bit angry with myself for not paying enough attention to the list ;(
Re: [PATCH] mod_disk_cache: store/read array table
Brian Akins wrote:
This is a rather nasty patch (sorry). Basically, it changes the way
arrays and tables are stored on disk. This allows us to do a much
cleaner and quicker read_array and read_table. It cuts down
significantly on the number of disk reads for header files (one big one)
and the number of strdup's (it used apr_table_addn, for example).
Bottom line is alot fewer system calls and allocations. It gives me a
5% increase in mod_disk_cache across the board.
does anyone have any objections to this patch?
5% is a pretty nice gain imho.
if I don't see anything in the next couple of days I'll commit it.
--- mod_disk_cache.c.orig 2006-01-18 13:44:55.0 -0500
+++ mod_disk_cache.c2006-01-20 09:48:23.0 -0500
@@ -40,15 +40,15 @@
* Format #1:
* apr_uint32_t format;
* apr_time_t expire;
- * apr_array_t vary_headers (delimited by CRLF)
+ * apr_array_t vary_headers (delimited by '\0')
*
* Format #2:
* disk_cache_info_t (first sizeof(apr_uint32_t) bytes is the format)
* entity name (dobj-name) [length is in disk_cache_info_t-name_len]
- * r-headers_out (delimited by CRLF)
- * CRLF
- * r-headers_in (delimited by CRLF)
- * CRLF
+ * length of r-headers_out
+ * r-headers_out (delimited by '\0')
+ * length r-headers_in
+ * r-headers_in (delimited by '\0')
*/
module AP_MODULE_DECLARE_DATA disk_cache_module;
@@ -60,8 +60,12 @@
static apr_status_t recall_headers(cache_handle_t *h, request_rec *r);
static apr_status_t recall_body(cache_handle_t *h, apr_pool_t *p,
apr_bucket_brigade *bb);
static apr_status_t read_array(request_rec *r, apr_array_header_t* arr,
- apr_file_t *file);
+ meta_file_t *file);
+static apr_status_t meta_file_close(void *data);
+static apr_status_t meta_file_open(meta_file_t **m, const char *file,
apr_pool_t *pool);
+static apr_status_t meta_file_read(meta_file_t *m, void **buf, apr_size_t
*nbytes);
+static apr_status_t meta_file_seek(meta_file_t *h, apr_off_t offset);
/*
* Local static functions
*/
@@ -195,46 +199,43 @@
* file for an ap_cache_el, this state information will be read
* and written transparent to clients of this module
*/
-static int file_cache_recall_mydata(apr_file_t *fd, cache_info *info,
+static int file_cache_recall_mydata(meta_file_t *fd, cache_info *info,
disk_cache_object_t *dobj, request_rec *r)
{
apr_status_t rv;
char *urlbuff;
-disk_cache_info_t disk_info;
+disk_cache_info_t *disk_info;
apr_size_t len;
/* read the data from the cache file */
len = sizeof(disk_cache_info_t);
-rv = apr_file_read_full(fd, disk_info, len, len);
+rv = meta_file_read(fd, (void **)disk_info, len);
if (rv != APR_SUCCESS) {
+/* Log error? */
return rv;
}
/* Store it away so we can get it later. */
-dobj-disk_info = disk_info;
+dobj-disk_info = *disk_info;
-info-status = disk_info.status;
-info-date = disk_info.date;
-info-expire = disk_info.expire;
-info-request_time = disk_info.request_time;
-info-response_time = disk_info.response_time;
-
-/* Note that we could optimize this by conditionally doing the palloc
- * depending upon the size. */
-urlbuff = apr_palloc(r-pool, disk_info.name_len + 1);
-len = disk_info.name_len;
-rv = apr_file_read_full(fd, urlbuff, len, len);
-if (rv != APR_SUCCESS) {
-return rv;
-}
-urlbuff[disk_info.name_len] = '\0';
+info-status = disk_info-status;
+info-date = disk_info-date;
+info-expire = disk_info-expire;
+info-request_time = disk_info-request_time;
+info-response_time = disk_info-response_time;
+
+len = disk_info-name_len;
+
+rv = meta_file_read(fd, (void **)urlbuff, len);
/* check that we have the same URL */
-/* Would strncmp be correct? */
-if (strcmp(urlbuff, dobj-name) != 0) {
+if (strcmp(dobj-name, urlbuff)) {
+ ap_log_error(APLOG_MARK, APLOG_INFO, 0, r-server,
+ disk_cache: name mismatch: %s != %s,
+ urlbuff, dobj-name);
return APR_EGENERAL;
}
-
+
return APR_SUCCESS;
}
@@ -347,7 +348,7 @@
static int open_entity(cache_handle_t *h, request_rec *r, const char *key)
{
-apr_uint32_t format;
+apr_uint32_t format, *tf;
apr_size_t len;
const char *nkey;
apr_status_t rc;
@@ -387,28 +388,32 @@
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);
+rc = meta_file_open(dobj-mf, dobj-hdrsfile, r-pool);
if (rc != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
+ disk_cache: meta_file_open);
return
[patch] FCGI -- pass path-info to FCGI process
this allows you to pass a 'path' to the fast cgi process
to use:
ProxyPass /forum fcgi-tcp://127.0.0.1:8005/foruX
request
/forum/zx will have a path_info of /foruX/zx
posting it as a patch, as the code is a bit fugly.
Index: mod_proxy_fcgi.c
===
--- mod_proxy_fcgi.c(revision 366086)
+++ mod_proxy_fcgi.c(working copy)
@@ -28,6 +28,7 @@
static int proxy_fcgi_canon(request_rec *r, char *url)
{
char *host, sport[7];
+char *path;
const char *err;
const char* scheme;
apr_port_t port = 8000;
@@ -62,8 +63,13 @@
host = apr_pstrcat(r-pool, [, host, ], NULL);
}
-r-filename = apr_pstrcat(r-pool, proxy:, scheme, host,
sport, /,
+path = ap_proxy_canonenc(r-pool, url, strlen(url), enc_path,
0, r-proxyreq);
+if (path == NULL)
+return HTTP_BAD_REQUEST;
+
+r-filename = apr_pstrcat(r-pool, proxy:, scheme, host,
sport, /, path,
NULL);
+
}
else if (strncmp(url, local://, 8) == 0) {
url += 6;
@@ -130,6 +136,7 @@
{
const apr_array_header_t *envarr;
const apr_table_entry_t *elts;
+char *path;
struct iovec vec[2];
fcgi_header header;
apr_size_t bodylen;
@@ -143,6 +150,18 @@
ap_add_common_vars(r);
ap_add_cgi_vars(r);
+if (r-path_info) {
+apr_table_setn(r-subprocess_env, PATH_INFO, r-path_info);
+}
+else {
+path = ap_strchr_c( r-filename,'/');
+if (path) {
+path = ap_strchr_c( path,':');
+}
+if (path) {
+apr_table_setn(r-subprocess_env, PATH_INFO,
ap_strchr_c(path, '/'));
+}
+}
/* XXX are there any FastCGI specific env vars we need to send? */
/* XXX What if there is over 64k worth of data in the env? */
fcgi
I'm not sure why we aren't just reading the plen at the same time as the
clen... but as is when the 2nd header is read, it is not in sync (out by
padding-len bytes)
this patch makes it read at the same time, and it seems to make the
handler work for larger responses (as the following header is now synced
up properly)
--i
Index: mod_proxy_fcgi.c
===
--- mod_proxy_fcgi.c(revision 365863)
+++ mod_proxy_fcgi.c(working copy)
@@ -517,15 +517,15 @@
plen = fheader[6];
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r-server,
-type %d request-id %d clen: % APR_SIZE_T_FMT plen %d,
+type %d request-id %d content len: % APR_SIZE_T_FMT
padding length %d,
type, rid,
clen, plen
);
recv_again:
-if (clen sizeof(readbuf) - 1) {
+if (clen +plen sizeof(readbuf) - 1) {
readbuflen = sizeof(readbuf) - 1;
} else {
-readbuflen = clen;
+readbuflen = clen+plen;
}
/* Now get the actual data. Yes it sucks to do this in a
second
@@ -582,11 +582,11 @@
/* If we didn't read all the data go back and get the
* rest of it. */
-if (clen readbuflen) {
+if (clen +plen readbuflen) {
clen -= readbuflen;
goto recv_again;
}
-
+/*
if (plen) {
readbuflen = plen;
@@ -595,6 +595,7 @@
break;
}
}
+*/
} else {
b = apr_bucket_eos_create(c-bucket_alloc);
@@ -611,6 +612,9 @@
case FCGI_STDERR:
/* XXX TODO FCGI_STDERR gets written to the log file. */
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server, %*s,
+readbuflen,
+readbuf );
break;
case FCGI_END_REQUEST:
apr_socket_sendfile not found on OS/X?
Hi. I just checked out the latest trunk of apr httpd on my mac, and can't build it anymore. it is complaining about apr_socket_sendfile not being defined. so I checked .. and apr.h has APR_HAS_SENDFILE as 0. the problem is sendfile_nonblocking calls apr_socket_sendfile ;(
Re: apr_socket_sendfile not found on OS/X?
Thanks Paul, I didn't realize the trunk wasn't 2.2.x.. otherwise I would have just fixed it myself ;-) Paul Querna wrote: Paul Querna wrote: Ian Holsman wrote: Hi. I just checked out the latest trunk of apr httpd on my mac, and can't build it anymore. it is complaining about apr_socket_sendfile not being defined. so I checked .. and apr.h has APR_HAS_SENDFILE as 0. the problem is sendfile_nonblocking calls apr_socket_sendfile ;( mac/darwin doesn't support sendfile at all. I don't know how you are getting sendfile_nonblocking called at all, since it is all wrapped by #if APR_HAS_SENDFILE -Paul Meh. Someone didn't wrap sendfile_nonblocking itself under APR_HAS_SENDFILE when they re-factored it :-) Fixed in trunk/r351997. -Paul
Re: mod_auth[nz]_dbd password caching
Hi Phil, A while back I wrote a auth wrapper which used a MD5 hash inside a cookie to determine if the user was authenticated. If the cookie was invalid or not present it would fall back to the regular auth method (in your case a DB hit). It also had a bit which sat just after the authentication section which would create the cookie on successful authentication. If you would like I could see if I can find this.. I don't think I actually made use of it after I wrote it ;( Phil Endecott wrote: Dear All, First of all, congratulation on the release of 2.2. I use mod_auth_pgsql at http://anyterm.org/my.html, and found a problem earlier in the year. To get reasonable performance you need to use the module's caching mechanism, but this cache is not flushed or updated when the database changes. So things don't work properly when the user changes their password. I started to think about fixing it myself but quickly realised that both the database and authentication frameworks were changing in 2.1+ and decided to wait before doing anything. I now see that 2.2 has mod_auth[nz]_dbd - great! However, as far as I can see from http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html and the source, this new module doesn't do any caching. Is this true? To get the sort of performance that I need for my site I really need in-memory caching of passwords, but I also need to solve mod_auth_pgsql's non-updating problem. The solution to this is to use PostgreSQL's asynchronous notification mechanism: the module issues a LISTEN command and is then notified when the password table changes. I don't know if the APR DB interface has any support for this (it doesn't seem to be documented at all at http://apr.apache.org/docs/apr-util/modules.html); even if it does, it is not portable to other databases. Has anyone looked at this? If no-one is working on this and you think it would be a useful feature to add, I may be able to write something with a bit of help. Cheers, --Phil.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Paul Querna wrote: My intention is for this to be a wide open brainstorming thread. I expect that we will be able to discuss several ideas in much more detail at the Hackathon next week, but I really want to get all ideas 'on the table'. I have a few things I would like to see, but I am sure there are perhaps hundreds of other major features that other people want. It helps to know what everyone else is thinking about new features, rather than one person going off an doing it all by themselves. (not that I'll stop anyone from that either). Here is my list: * Async/Event MPM: Complete Async pipeline for static files. I believe we can seriously give every existing single-threaded-event-based server a run for their money on every existing benchmark. Toss in some dynamic content, and a hybrid Event/Worker has serious potential. Some of this work is ongoing in the async-read dev branch, but there is plenty more to do. I've always wanted to (but not had free time) to write a SEDA-type mpm. the SEDA is slightly different to the async/event mpm in that a given hook/filter would process multiple events/requests at the same context switch. This is what the apr_queue stuff was initially designed for. I'd also like to brainstorm a better solution to running Rails/Django applications inside of the httpd process than the SCGI/FastCGI solution which most people use. Configuration .. make it configurable. by that I mean allowing people to use LDAP or a DB to hold the configuration files, and not a flat file. This is mainly intended for large server farms. Currently the main reason for logging onto a webserver is to change it's configuration (and bounce) .. if we could reduce that to just 'bounce' it might make life easier. (or some method where it checks configs every X minutes and autobounces..removing the need to log onto the machine at all ;-) Configuration .. make it easier..I can't think of anything on how to do this off the top of my head, but it seems to be a common complaint. Logging/debugging .. changing the log system to use something like Log4C for errors.. this way the module developer can easily turn on/off various information on a live system when he is having issues. wish I could attend the ApacheCon.. if there was a ApacheCon OZ I'd be there ;-) regards Ian
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Garrett Rooney wrote: On 12/3/05, Ian Holsman [EMAIL PROTECTED] wrote: I'd also like to brainstorm a better solution to running Rails/Django applications inside of the httpd process than the SCGI/FastCGI solution which most people use. Out of curiosity, what do you think is wrong with the current FastCGI method of running them? configuration. for example in order for me to get typo running on my blog, I need 4 rewrite rules. (and when I tried to do something slightly different, it took me a good hour to configure it properly with all the rewrite magic) also when applications 'experts' like scott (the creator of typo) have issues like http://scottstuff.net/blog/articles/2005/07/20/apache-tuning-for-rails-and-fastcgi i think it isn't easy enough to run. what I am after is something as simple as RailsApp /foo/ rails-controller.rb [cache] [ENV=production] which would just work as a in-process application... making it as simple as running a PHP application is the goal. I don't like the trend i see with rails django people saying apache is hard to use and switching to other web servers. -garrett
Re: What's up for mod_mbox ?
Maxime Petazzoni wrote: Hi, It's been one month that my SoC project is now over. I even received the money from Google. Thanks again to all of you for your help and support during the summer. For now, I would really like to see something moving around mod_mbox. I did not get any news from the httpd-mbox-search guy, nor from my vote about merging my changes to mod_mbox's trunk. So, what's up ? Have my changes been reviewed ? Or at least tested ? Please note that I plan to merge my changes myself on Saturday, October 1st (one month after the SoC deadline, 100 days after SoC begining). I really want to see this stuff setup and available to m-a.a.org users. +1 on merging the branch. regards Ian. Thanks for your attention, - Sam
Re: mod_dbd
I don't see why not. Committed. regards Ian Brian J. France wrote: Any reason why this patch couldn't be applied to allow the option of building mod_dbd? The title might need a little tweaking. Thanks, Brian - with no commit access Index: modules/experimental/config.m4 === --- modules/experimental/config.m4 (revision 279774) +++ modules/experimental/config.m4 (working copy) @@ -13,5 +13,6 @@ APACHE_MODULE(case_filter, example uppercase conversion filter, , , no) APACHE_MODULE(case_filter_in, example uppercase conversion input filter, , , no) APACHE_MODULE(filter, smart filtering module, , , no) +APACHE_MODULE(dbd, Apache DBD Framework, , , no) APACHE_MODPATH_FINISH
Re: Proposed connection state diagram
Brian Pane wrote: On the subject of asynchronous write completion, I've drawn a connection state model that combines the current state transitions of the event MPM with new states for write completion and the handler phase. Comments welcome... Am I missing any state transitions (particularly for error cases)? Should there be an access logger state? Are there other good use cases to consider for a nonblocking handler feature, besides mod_proxy? http://www.brianp.net/work/opensource/apache/async.html Thanks, Brian It's late over here.. so I'm sure I'm being stupid.. but here are some things I can't see transitions for: are you missing the case where the client disconnects mid-request (CONN_STATE_READ_REQUEST_LINE - Connection_deleted) and when the client disconnects mid-response? CONN_STATE_HANDLER/CONN_STATE_WRITE_COMPLETION - Connection_deleted) case where the client connects/disconnects (TCP-port check) as for non-blocking cases.. when the module needs to issue a TCP/UDP connection to a 3rd party. (eg.. gets a stock quote or performs a LDAP check for authorization, or wordpress doing a trackback/pingback) what about mod-rewrite spawning a program to do a rewrite mapping? like I said at the start.. I'm sure I'm being stupid and not understanding the questions ;-) --ian
Re: What happened to the Apache 2 cross reference?
Brandon Fosdick wrote: For a month or two now I've been using the cross reference that was linked from the developer documentation page. Then it went away for awhile and now its back with some weird crippled version that can't do wild card searches for identifiers. The source navigation is broken too. eg. If you try to decend into the modules/dav/fs directory you get sent back to the top. What happened? If you are refering to http://docx.webperf.org http://lxr.webperf.org they suffered a machine move. http://docx.webperf.org is back up now (and looks a bit prettier IMHO) http://lxr.webperf.org will be fixed in the next week or so. I'm might take Rachel's queue and stick some ads on the page, I can use the extra $1 or 2 it will make. regards ian
Re: Doxygen
Hi Neale. I'll go through and review the patch today. I'll try to get it commited in a couple of hours. Neale Ranns wrote: Sander, I put a patch here (http://www.ranns.org/~ndrr/apache2/), it's kinda big to be emailing to all. There is also a tar ball there of the html files if anyone would like a copy. i am working from an up to date version of the svn trunk. thnaks neale On Fri, 2005-08-19 at 19:05, Sander Temme wrote: Hi Neale, On Aug 19, 2005, at 7:55 AM, Neale Ranns wrote: Over the past few days i've been reading around the source code and improving the doxygen documentation. You can see the results here. http://www.ranns.org/~ndrr/apache2/dox/html/index.html Very cool. Could you produce a patch using diff -u? What version of the source code are you working with? Thanks, Sander Essentially what i have done is: 1) change all the @package (since these generate Namespaces) to @defgroup (which produces the grouping in the Modules page) 2) Added lots more @defgroup to get the module grouping on the Modules page 3) Add a @file and @brief to each header file to improve the File List page 4) Did some improvements to function and struct declarations; though by no means all. There is a long way to go. 5) lastly i changed the doxygen.conf file: a) to make the output searchable b) to extract everything (otherwise the undocumented stuff is left out) c) added a hack so the CORE_PRIVATE stuff is included d) fixed the STRIP_FROM_PATH problem, by setting it to STRIP_FROM_PATH= which implies, the directory from which doxygen is run. It is possible to do with autoconf but more complicated. comments always welcome :) thanks neale
Re: CTR policy for experimental modules in A2.0?
Jim Jagielski wrote: I have a bug I'd like to squash in mod_auth_ldap.c in 2.0 that doesn't exist in 2.1/2.2 (non-existent authn_ldap_request_t req struct during auth check)... since the module is experimental, can I assume CTR ? Hey Jim can you post the patch ? while this discussion about RTC/CTR is fantastic and all.. I'd love to get the patch into the code.. so post it. we can all review it onlist (like the good ol days) and give you some +/- 1's /feedback on here. (speaking with my ldap-user hat on)
Re: How long until 2.2
Akins, Brian wrote: As I sit here debugging our home grown proxy code for 2.0, I wonder how long until 2.2? We wrote our own proxy because the cool 2.1 stuff was not out at the time. The new proxy stuff would be wonderful for us, but noone wants to run alpha code in production. (However, we are quick to run homegrown stuff...) So, please, I be you -- give us 2.2 ;) May I suggest you put the following proposal to your management. cost of devoting a senior engineer for the next month or two to help 'field test' apache 2.2 in a high scale environment, identifying and submitting patches to 2.2 is Y. This should be considered a sunk cost. you will have to perform this test now, or in 2-3 months time when we officially release it as 2.2. The only advantage of waiting is that you hope someone else will find the same problems as your team would. The disadvantages of waiting - your changes you testing find might not be able to be applied to the main core, as altering a 'production' system takes more checks and paperwork than a developmental one. so you will be stuck in the same situation you are now.. maintaining a patched up apache. - If you get organized now, you might be able to distribute the testing phase with other large companies in a similar situation to you. This might reduce the cost of 'Y', or allow you to concentrate on the features you care more about, knowing that other people will be doing other parts of the testing as well. (ie.. sharing the cost of 'Y' over multiple companies). so to summarize.. get your testing team into the 2.1 code now, and you will have a more stable 2.2 when it comes out, and you might even convince your management that version numbers don't mean squat in a open source world. Cheers Ian Thanks.
Re: [PATCH] Improved doxygen output for http_connection.h
Hi Neale
what does removing the package line do?
doesn't it remove the function from their grouping on the modules page?
and the removal of the deffunc prototype... why?
Neale Ranns wrote:
hi,
I'm new to the project and have been reading the code to see how it all
works and i've been fixing the doxygen (version 1.4.4) tags as i go.
attached a patch for http_connection.h based on the version on the trunk
i checked out from subversion this morning.
If it's useful and you'd like more let me know. If someone else is
already working on this, then I'll just read.
thanks
neale
Index: include/http_connection.h
===
--- include/http_connection.h (revision 227319)
+++ include/http_connection.h (working copy)
@@ -14,6 +14,11 @@
* limitations under the License.
*/
+/**
+ * @file http_connection.h
+ * @brief Apache connection library
+ */
+
#ifndef APACHE_HTTP_CONNECTION_H
#define APACHE_HTTP_CONNECTION_H
@@ -25,9 +30,6 @@
extern C {
#endif
-/**
- * @package Apache connection library
- */
#ifdef CORE_PRIVATE
/**
* This is the protocol module driver. This calls all of the
@@ -36,10 +38,13 @@
* @param csd The mechanism on which this connection is to be read.
*Most times this will be a socket, but it is up to the module
*that accepts the request to determine the exact type.
- * @deffunc void ap_process_connection(conn_rec *c, void *csd)
*/
AP_CORE_DECLARE(void) ap_process_connection(conn_rec *c, void *csd);
+/**
+ * Flushes all remain data in the client send buffer
+ * @param c The connection to flush
+ */
AP_CORE_DECLARE(void) ap_flush_conn(conn_rec *c);
/**
@@ -70,10 +75,12 @@
* if it encounters a fatal error condition.
*
* @param p The pool from which to allocate the connection record
+ * @param server The server record to create the connection too.
* @param csd The socket that has been accepted
* @param conn_id A unique identifier for this connection. The ID only
*needs to be unique at that time, not forever.
* @param sbh A handle to scoreboard information for this connection.
+ * @param alloc The bucket allocator to use for all bucket/brigade creations
* @return An allocated connection record or NULL.
*/
AP_DECLARE_HOOK(conn_rec *, create_connection,
@@ -89,7 +96,6 @@
*Most times this will be a socket, but it is up to the module
*that accepts the request to determine the exact type.
* @return OK or DECLINED
- * @deffunc int ap_run_pre_connection(conn_rec *c, void *csd)
*/
AP_DECLARE_HOOK(int,pre_connection,(conn_rec *c, void *csd))
@@ -100,12 +106,10 @@
* to handle the request is the last module run.
* @param c The connection on which the request has been received.
* @return OK or DECLINED
- * @deffunc int ap_run_process_connection(conn_rec *c)
*/
AP_DECLARE_HOOK(int,process_connection,(conn_rec *c))
-/* End Of Connection (EOC) bucket */
-
+/** End Of Connection (EOC) bucket */
AP_DECLARE_DATA extern const apr_bucket_type_t ap_bucket_type_eoc;
/**
@@ -119,7 +123,6 @@
* Make the bucket passed in an End Of Connection (EOC) bucket
* @param b The bucket to make into an EOC bucket
* @return The new bucket, or NULL if allocation failed
- * @deffunc apr_bucket *ap_bucket_eoc_make(apr_bucket *b)
*/
AP_DECLARE(apr_bucket *) ap_bucket_eoc_make(apr_bucket *b);
@@ -128,7 +131,6 @@
* that the connection will be closed.
* @param list The freelist from which this bucket should be allocated
* @return The new bucket, or NULL if allocation failed
- * @deffunc apr_bucket *ap_bucket_eoc_create(apr_bucket_alloc_t *list)
*/
AP_DECLARE(apr_bucket *) ap_bucket_eoc_create(apr_bucket_alloc_t *list);
Re: mod-cache-requestor plan
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: svn commit: r219372 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h modules/proxy/mod_proxy.c modules/proxy/mod_proxy.h
William A. Rowe, Jr. wrote: At 12:12 AM 7/17/2005, [EMAIL PROTECTED] wrote: Author: ianh Date: Sat Jul 16 22:12:10 2005 New Revision: 219372 URL: http://svn.apache.org/viewcvs?rev=219372view=rev Log: This patch adds a new hook (request_status) that gets ran in proxy_handler just before the final return. This gives modules an opportunity to do something based on the proxy status. [...] new hook -- so mmn bump.. i made it a major one, hope thats ok We only bump major when we -change- an existing API or drop an API which is no longer supported. E.g. anyone using the old major might have been using something we no longer provide. ok.. I'll go fix the structure. I wasn't sure what the difference was. A new structure member (at the end of an httpd-allocated structure) or new function are minor bumps; which this patch falls under. The user updating should not need to update their module, because the expectations when such modules were built have not changed. Bill
Re: mod-cache-requestor plan
Parin Shah wrote: On 7/15/05, Colm MacCarthaigh [EMAIL PROTECTED] wrote: On Fri, Jul 15, 2005 at 01:23:29AM -0500, Parin Shah wrote: - we need to maintain a counter for url in this case which would decide the priority of the url. But mainting this counter should be a low overhead operation, I believe. Is a counter strictly speaking the right approach? Why not a time of last access? I havn't run a statistical analysis but based on my logs the likelyhood of a url being accessed is very highly correlated to how recently it has been accessed before. A truly popular page will always have been accessed recently, a page that is becoming popular (and therefore very likely to get future hits) will have been accessed recently and a page who's popularity is rapidly diminishing will not have been accessed recently. Last Access Time is definetaly better solution when compared to counter mechanism. Would like to know other ppl's opinion too. you should be using a mix of # requests last access time cost of reproducing the request. 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. Thanks, Parin.
Re: [PATCH] new proxy hook 2.1
Akins, Brian wrote: This patch adds a new hook (request_status) that gets ran in proxy_handler just before the final return. This gives modules an opportunity to do something based on the proxy status. A couple of examples where this is useful: -You are using a caching module and would rather return stale content rather than an error to the client if the origin is down. -you proxy some subrequests (using SSI - mod_include) and do not want SSI errors when the backend is down. If you would normally return HTTP_BAD_GATEWAY, you may have a module that serves some other content. This feature is one of the features of our in house proxy module that keeps us from moving toward the stock 2.1 proxy. Thanks Brian. I applied this patch, and also bumped the mmn # for the new hook Regards Ian
Re: mod-cache-requestor plan
Akins, Brian wrote: On 7/13/05 6:41 PM, Ian Holsman [EMAIL PROTECTED] wrote: a pool of threads read the queue and start fetching the content, and re-filling the cache with fresh responses. How is this better than simply having an external cron job to fetch the urls? You have total control of throttling there and it doesn't muck up the cache code. A good idea may be to have a cache store hook that gets called after a cache object is stored. In it, another module could keep track of cached url's. This list could be feed to the above cron job. I know one big web site that may do it in a similar way... that wouldn't keep track of the popularity of the given url, only when it is stored. I'm guessing the popularity of news stories in CNN is directly proportional to if they are linked off one of the doors or if they have just been published. other large sites (for example product reviews, or things like webshots.com) get most of their traffic indirectly via searches, and not directly from a link on a door for example. and have traffic patterns more like a ZipF distribution. The priority re-fetch would make sure the popular pages are always in cache, while others are allowed to die at their expense. BTW. I'm not saying it's better, I'm just saying it's different, and news sites aren't the only large sites in town who need caches. Regards Ian
Re: mod-cache-requestor plan
This was a private message. I will continue this one offline. Akins, Brian wrote: On 7/13/05 6:36 PM, Ian Holsman [EMAIL PROTECTED] wrote: Hi There. just remember that this project is Parin's SoC project, and he is expected to do the code on it. sure. I am expected to do what's best for my employer and the httpd project. While normally I think it would be great to get a patch, we need parin to do the work on this, otherwise he might get a bit upset when it comes to getting paid. He can have the patch. I just want to see it done right.
Re: mod_mbox: js speed and mbox size
Bill Stoddard wrote: Maxime Petazzoni wrote: Hi, 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. After setting up a browser stub, I'm not going to concentrate on compatibility and speed problems before continuing. In fact, there are two main problems implied by the current mechanism : - On large mailboxes, the /ajax/msglist query reply can get *very* large. As an example, this mailing list's 2001-08 archives contains 1708 messages, and the corresponding XML is 452492 bytes big. This is too much. As a comparison, the old mod_mbox resulting page for the same month is only 311 KB big. mod_deflate should be able to help with that. XML (or any text) compresses real well. As a solution to this, Ian advised the use of LiveGrid (http://openrico.org/livegrid.page). It fetches only the piece of data that need to be displayed (ten, twenty, ... rows instead of the whole 1700+). I don't really like this solution because the user must scroll the table, and then wait for the data to appear, etc. Isn't this where XmlHttpRequest comes in handy? Asynchronously fetch X (a hundred?) rows forward from where the user is currently looking in anticipation that that user will scroll forward. So you don't slurp down the whole mailbox at once, but you try to stay ahead of what the user might be expected to do and always have some data ready to display. That is what openrico do I'm guessing. they just provide a set of higher level API's to manage that. And that we don't get the whole list (no in-page search for example). Another solution would be to use a page system as in the Debian mailing list archives, displaying 100 or 200 messages per page only. This would reduce bandwidth usage, but it will also make things harder when updating the context box. For the moment, the message list is fetched once, and all operations are made on this stored list. When updating the context box, we just take -3 to +3 messages from the list. With the page system, we'll experience problems while approaching the end of a page ... - The second problem is brought by the first one. On large mailboxes, the Javascript processing takes too much time. Building all elements each time the message list is displayed (at loading time or when you close a message box) does not make the application usable. would preprocessing (and caching) some of this stuff on the server help? it might make your 450k XML file larger, but you could provide some of the thread info in the XML file itself. 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 ? yes. I've done a bit, and it is yuk this is why I suggested openrico .. they have done all of this for you, and have their code used by a wider range of people. the code has a ASL2 licence.. it is perfect for httpd. Heh, you wish :0 This is a cool project, glad it's on the httpd dev list. Bill
Re: mod_cache new directive
Sergio Leonardi wrote: Hi all I'm a newbie and I'd like to plan to add to mod_cache a directive like this one, if possible. What could be the correct procedure to do it? Am I sending the message to the wrong place? Hi Sergio. It sounds like a great idea. How do you plan on implementing such a beast? Last Time i checked (a while ago) mod_mem_cache was process-based memory (not shared). So I'm just a bit unsure how a single request is going to flag to the other processes that it needs to clear a regex pattern, or are you planning on implementing this just for disk-based cacheS? Regards Ian CacheClear Directive Description: http://httpd.apache.org/docs-2.0/mod/directive-dict.html#Description Clear the cache for the URI that matches the pattern Syntax: http://httpd.apache.org/docs-2.0/mod/directive-dict.html#Syntax CacheClear uri-pattern Default: http://httpd.apache.org/docs-2.0/mod/directive-dict.html#Default CacheClear /.* http://httpd.apache.org/docs-2.0/mod/directive-dict.html#Context Context: ?? Status: http://httpd.apache.org/docs-2.0/mod/directive-dict.html#Status Experimental Module: http://httpd.apache.org/docs-2.0/mod/directive-dict.html#Module mod_cache More detail will be added here, when the function is implemented. CacheClear /daily_scripts/.*
Re: Move to dev@httpd?
+1 On 7/1/05, Paul Querna [EMAIL PROTECTED] wrote: I believe that we should close down [EMAIL PROTECTED], and move all discussion of this project to [EMAIL PROTECTED] This way more people can see some of the really cool things going on, and we get much better review of ideas than the very limited list of people that are on mbox-dev. Thoughts? -Paul -- [EMAIL PROTECTED] -- 03-9877-0909 If everything seems under control, you're not going fast enough. - Mario Andretti
Re: Monitoring HTTP error logs
Henri Gomez wrote: Hi to all, Did you know a tools on Unix/Linux system, which should be able to monitor in real-time the error_log of Apache2 servers and for example, send email/syslog message when a [error] string is detected ? Regards and thanks for your help look for a tool called 'logtail' ' It will remember the last position it was in the file its tailing (and start from there the next time). I also have some perl scripts which do counts on regex matches in error logs. I can scratch around for you if SEC/Swatch isn't working out. regards Ian
Re: mod_smtpd project planning
Roy T. Fielding wrote: On Jun 28, 2005, at 4:20 PM, Paul Querna wrote: So, to accommodate this, we would need a mod_smtpd space in subversion and a [EMAIL PROTECTED] mailing list. -1. The point of SoC is to get more people involved in open source projects, not to encourage the ASF to accept non-collaborative code bases in exchange for a bit of cash. Use the main dev list and encourage the students to participate in the larger project as well as the specific one. Roy and where do we put the code? we've got another SoC project in the same spot. httpd-bandwidth-limit. (one to limit DoS/bandwidth hogs) Roy.. are you recommending we put both modules in the experimental area?
Re: About mod_mbox future improvements
re-send to list On 6/27/05, Ian Holsman [EMAIL PROTECTED] wrote: you can make the XSLT 'standard' enough to handle both IE and firefox (and Safari) aim to do this. If you have some XSLT transform which you need and can't be done on IE, then we might need to fallback to mod_transform, but I think you should set your sights high. I am a fan of getting the client to do it ;-) serving XML out can also enable 3rd paty apps which you haven't thought of yet to do neat things with the output as well. regards Ian On 6/27/05, Maxime Petazzoni [EMAIL PROTECTED] wrote: Hi, I am still worried about the portability of client-side processing. Between all the versions of all the browsers, doing complicated things seems to be hit and miss to me. So are we. As I said, only Gecko based browser can handle it, and I don't believe it's good to narrow the users range like this. With an XSLT Cache, which mod_transform has, it can render very quickly. I am a fan of Server-side processing for XSLT. Ok, I'll try to set up mod_transform with the XSLT Cache tonight on my local mod_mbox installation and see how all this stuff works. We still need to make a decision as a group, do we want XSLT? Do we want an alternative such as ClearSilver templates? Do we just want 'better' HTML and CSS? According to me, XML+XSLT is the most evolutive solution. Except from the wanted AJAX stuff, we could also easily build advanced XUL applications on top of this XML output (just an idea, though). I believe that since the work is already in progress for XSLT, that makes it a good choice for now. The decision on server-side vs client-side is interesting, and perhaps we can meet some middle ground, but for now, I think we should pursue server-side processing. /me's diving into server-side processing :) - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. BodyID:237727064.2.n.logpart (stored separately) -- [EMAIL PROTECTED] -- 03-9877-0909 If everything seems under control, you're not going fast enough. - Mario Andretti -- [EMAIL PROTECTED] -- 03-9877-0909 If everything seems under control, you're not going fast enough. - Mario Andretti
Apache Webserver Usage Survey
Hi. I am conducting a survey about what users want out of a webserver and how the Apache webserver ranks as far as fulfilling those needs. In order to get a better understanding of it, I thought I would ask you guys what was important to you. The survey should take about 10-15 minutes to complete. http://survey.zilbo.com/dev.survey I wish I could say there was a prize being given away if you fill it out, but there isn't.. This is 'opensource' research.. I don't have a marketing budget ;-) Regards Ian Holsman [EMAIL PROTECTED]
Out of Office AutoReply:
Title: Out of Office AutoReply: i am currently out of the office until May 23rd. if the matter is urgent, please contact tech-pma or my manager Paul Osterhus
Re: Actively Promoting Apache 2
The biggest hurdle 2.0 has had to face IMO is: - 1.3 isn't broken - we run 1.3 already - module XYZ only runs on 1.3 - 2.0 doesn't do anything that 1.3 doesn't do anyway What I would suggest for your marketing campaign would be to write and submit several technical articles about apache2 and how its new features and speed can help you save money, reduce administration time, and enable a whole heap of new features from already written modules which you would have had to custom develop yourself in 1.3. Also I would start discussing with some of the other 1.3-only module writers out there on how to port their stuff to 2.0, or port it for them. Marketing is about knowing your customers, and servicing their needs. It is not about selling products or brainwashing ;-) --Ian Wayne S. Frazee wrote: I entreat each potential responder to this email to please read it all the way through and THEN respond rather than knee-jerk something based on only the first paragraph or two... As I sat reading the responses to the new development thread on acceptance of Apache 2 and some users' regression to 1.3, it struck me when someone mentioned that they believed part of the problem to be marketing. Mozilla advertised firefox with a large one-time investment into a celebratory ad denoting the release of Firefox 1... why not build a similar effort in the Apache community to promote support and upgrade to Apache 2? Use the web-media and the advertising avenues in many high-traffic sites dealing specifically with web development, web hosting, ISP hosting, et al. Launch limited time and expense ad campaigns using media provided and approved by the community. Use funding from a community Apache Promotion drive. I was thinking something like this: 1) Launch fundraising / contest website for Apache 2.x ad blitz promotion. 2) Announce contest to have your flash ad featured on websites around the web in the Apache 2 Promotion ad campaign. Vehicle to submit ad, et al. 3) Announce fundraising effort to support above-mentioned ad with funds being specifically earmarked for this effort. If the effort is done by someone or a group of someones in the community, accounting needs to be very transparent and availible for public view in terms of limited statistics on the fundraising status. Donators who wish may have thier names or pseudo-names credited to a list of donators, sorted by contribution size or something of that nature? 4) At the end of the flash ad submission period, contest judges from the apache community select the editors top 5 or whatever for each ad format. For an announced period of time, the community at large is welcome to vote for thier favorite among the ads in essentially a web poll. 5) Following ad selection, collected funds are assessed, donations are no longer accepted, and a panel of whoever is working on the effort assesses the best ad channels and the panel comes to an agreement on the allocation of specific fund segments to various ad campaigns that are deemed to be the most effective channel for the selected ads. 6) Ad campaigns are run until budget is met, project over. Benefits: High visiblility from tech news organizations covering the drive, similar to the mozilla projects' fundraiser. Targeted advertisements for the apache 2 project with a credits page for each selected ad awarded to the contest winner(s). The message of upgrade to apache 2 is out there, hopefully with good, professional-looking ads contributed by the community, et al. Challenges: Numerous, I am sure. Looking for feedback, legal, devils advocate, et al on the concept, if not the execution. - Wayne S. Frazee Any sufficiently developed bug is indistinguishable from a feature.
Re: Apache HTTP Server 2.1.2 tagged...
Paul Querna wrote: +1 for promoting it to beta status. +1 for making it beta.. time to get some more people to shake the bugs out. been using it on OS/X for a while now and it seems not to crash every 5 seconds ;-) Ian
2.1 build broken ?
hi. I'm building from a clean slate (new box) and am having issues building it. It seems not to be including the stuff in listen.c its OS/X 10.3.6 with november's gcc patch.. no fink on it either. /ex/build-1/libtool --silent --mode=link gcc -faltivec -mcpu=7450 -mtune=7450 -mpowerpc -mpowerpc-gfxopt -g -O2 -faltivec -mcpu=7450 -mtune=7450 -mpowerpc -mpowerpc-gfxopt -L/ex/lib -L/ex -o httpd modules.lo -export-dynamic server/libmain.la modules/aaa/libmod_authn_file.la modules/aaa/libmod_authn_default.la modules/aaa/libmod_authz_host.la modules/aaa/libmod_authz_groupfile.la modules/aaa/libmod_authz_user.la modules/aaa/libmod_authz_default.la modules/aaa/libmod_auth_basic.la modules/filters/libmod_include.la modules/loggers/libmod_log_config.la modules/metadata/libmod_env.la modules/metadata/libmod_setenvif.la modules/http/libmod_http.la modules/http/libmod_mime.la modules/generators/libmod_status.la modules/generators/libmod_autoindex.la modules/generators/libmod_asis.la modules/generators/libmod_cgid.la modules/mappers/libmod_negotiation.la modules/mappers/libmod_dir.la modules/mappers/libmod_imap.la modules/mappers/libmod_actions.la modules/mappers/libmod_userdir.la modules/mappers/libmod_alias.la modules/mappers/libmod_so.la server/mpm/worker/libworker.la os/unix/libos.la /src/asf/httpd/srclib/pcre/libpcre.la /ex/lib/libaprutil-1.la -ldb-4.3 -lexpat -liconv /ex/lib/libapr-1.la -lpthread ld: warning multiple definitions of symbol _regcomp /src/asf/httpd/srclib/pcre/.libs/libpcre.a(pcreposix.o) definition of _regcomp in section (__TEXT,__text) /usr/lib/libpthread.dylib(regcomp.So) definition of _regcomp ld: warning multiple definitions of symbol _regexec /src/asf/httpd/srclib/pcre/.libs/libpcre.a(pcreposix.o) definition of _regexec in section (__TEXT,__text) /usr/lib/libpthread.dylib(regexec.So) definition of _regexec ld: warning multiple definitions of symbol _regfree /src/asf/httpd/srclib/pcre/.libs/libpcre.a(pcreposix.o) definition of _regfree in section (__TEXT,__text) /usr/lib/libpthread.dylib(regfree.So) definition of _regfree ld: Undefined symbols: _ap_listen_pre_config _ap_listeners _ap_set_listenbacklog _ap_set_listener _ap_set_send_buffer_size _ap_setup_listeners make[1]: *** [httpd] Error 1 make: *** [all-recursive] Error 1 Helios:/src/asf/httpd ianh$
Re: More musings about asynchronous MPMs Re: Event MPM
Bill Stoddard wrote: Brian Pane wrote: Paul Querna wrote: Paul Querna wrote: A thread per-connection that is currently being processed. Yeah, SEDA's model of processing stages--basically a succession of thread pools through which a request passes, each with a queue in front--looks like a promising way of mixing event-based and non-event-based processing. Thread context switches will suck performance out of any SEDA implementation. If I remember correctly SEDA got around this by passing the thread through if the queue was empty, and batching up requests so that instead of processing one request in a stage you would handle X at a time. For sure. Brian
Re: Whitespace strip filter for httpd v2.1
Cliff Woolley wrote: On Mon, 22 Nov 2004, Graham Leggett wrote: I have attached a small filter module that strips leading whitespace from text files. This would typically be used to remove the indenting whitespace found inside HTML files, resulting in a significant reduction in network traffic for some sites. I didn't bother to include trailing whitespace removal, as this involved buffering (leading whitespace removal requires no buffering). Well, we've had people submit modules in the past that stripped the extraneous whitespace from HTML files, and we rejected them. Check the archives for messages from a guy named fabio rohrich, who wrote a module called mod_blank to see why that might have been. I don't completely remember the details. In a nutshell, it is very hard to strip whitespace out of HTML, and have the resulting file still be as valid as the old one. Browsers are very forgiving on something and not on others. for example, you should not strip code inside of javascript, or 'pre' tags. --Cliff
Re: People still using v1.3 - finding out why
Matthieu Estrade wrote: I think people rely on apache 1.3 stability and security. many people consider httpd-2.0 as too young and don't try to understand why it's better. Does somebody have some percentage about 1.3 use and 2.0 ? I don't think 1.3 is still here because of modules, there is too many modules and too many kind to use apache (perl, php, proxy, cache + deflate, etc...) Is php not stable with 2.0 prefork ??? It is stable. I'm sure you can get it to segfault if you tried, but the same goes with 1.3. But what i don't understand, is how people can say apache 1.3 is better to code with, than apache 2.0. filters are so usefull. it's a pleasure everyday to code with apache 2.0 :] I never thought it was a matter of coding, It's more a matter of porting. From the conversations I hear/see it is the module developer who runs 1.3 and is quite happy with it for their needs. The other factor I see in the 'auth' category of modules is that the API has changed radically in 2.1, and so some people have just skipped 2.0 for their modules. --Ian I'm waiting for the people still using v2.0 when 2.2 goes stable. regards, Matthieu
Re: 2.2 roadmap meeting tomorrow
Cliff Woolley wrote: For any committers interested: we're going to do a lunch meeting tomorrow (Monday) over lunch. Place TBA. I propose Hamburger Mary's since it's close and I haven't been there yet this year. --Cliff would you care to post a abbreivated dialouge/notes from the meeting up here? (for us poor slobs not able to go to Vegas this year)
Re: make the server not to start in case the Initialization is a failure
[EMAIL PROTECTED] wrote:
Hi All,
I am trying to write a sample Plugin on APACHE 2.0 which does some
initialization.
I am attaching the code portion for the same.
static void mod_register_hooks(apr_pool_t *p)
{
ap_hook_child_init(mod_init_Child, NULL,NULL, APR_HOOK_FIRST);
ap_hook_check_user_id (mod_auth,NULL,NULL, APR_HOOK_FIRST);
}
module AP_MODULE_DECLARE_DATA sm_mod_auth = {
STANDARD20_MODULE_STUFF,
NULL, /* create per-dirconfig structures */
NULL,/* merge per-dirconfig structures */
NULL, /* create per-server config structures */
NULL,/* merge per-server config structures */
NULL,/* table of configuration directives */
mod_register_hooks /* register hooks */
};
static int mod_init_Child(server_rec* pServerRec, apr_pool_t* pPool)
{
int nRet = FALSE;
printf(Inside Child Auth Module\n);
nRet = InitConfigFile(pPool);
if (nRet == FALSE)
return FALSE;
else
return TRUE;
}
How do make the server not to start in case the Initialization is a
failure.
The same used to work on apache 1.3x in case I returned exit(2), but its
not working with apache 2.0.
Any help ???
can you init the config file in a post-config hook instead of the child?
that can cause the apache to not start.
FWIW.. you haven't considered the case where init-child is executed on a
running server for a new-process. would you like the entire server to
fail because it couldn't spawn a new process for example? (even though
the other children are quite happily serving requests)
Thanks in advance
Ian
Confidentiality Notice
The information contained in this electronic message and any attachments to this
message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged
information. If
you are not the intended recipient, please notify the sender at Wipro or [EMAIL
PROTECTED] immediately
and destroy all copies of this message and any attachments.
Re: mod_cache 2 questions
Justin Erenkrantz wrote:
--On Tuesday, September 7, 2004 2:48 PM +1000 Ian Holsman
[EMAIL PROTECTED] wrote:
Not really, but I'd like to see a patch posted to this list first before
committing it. There's a couple ways I could see implementing this, but
not sure which way you are intending to do this. -- justin
here is the patch I initially did, but I like Bill's idea about adding a
default expiry as well... which could be done in a different way.
ianh:/src/httpd-2.0/modules/experimental ianh$ cvs diff -u
Index: mod_cache.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.c,v
retrieving revision 1.64.2.14
diff -u -u -r1.64.2.14 mod_cache.c
--- mod_cache.c 26 Aug 2004 16:59:44 - 1.64.2.14
+++ mod_cache.c 8 Sep 2004 06:13:12 -
@@ -445,7 +445,7 @@
/* if a broken Expires header is present, don't cache it */
reason = apr_pstrcat(p, Broken expires header: , exps, NULL);
}
-else if (r-args exps == NULL) {
+else if (r-args exps == NULL (conf-no_expires == 0)) {
/* if query string present but no expiration time, don't cache it
* (RFC 2616/13.9)
*/
@@ -747,6 +747,9 @@
ps-complete_set = 0;
ps-no_last_mod_ignore_set = 0;
ps-no_last_mod_ignore = 0;
+
+ps-no_expires_set = 0;
+ps-no_expires = 0;
ps-ignorecachecontrol = 0;
ps-ignorecachecontrol_set = 0 ;
return ps;
@@ -781,6 +784,12 @@
(overrides-no_last_mod_ignore_set == 0)
? base-no_last_mod_ignore
: overrides-no_last_mod_ignore;
+
+ps-no_expires=
+(overrides-no_expires_set == 0)
+? base-no_expires
+: overrides-no_expires;
+
ps-ignorecachecontrol =
(overrides-ignorecachecontrol_set == 0)
? base-ignorecachecontrol
@@ -800,7 +809,19 @@
return NULL;
}
+static const char *set_cache_ignore_no_expires(cmd_parms *parms, void
*dummy,
+int flag)
+{
+cache_server_conf *conf;
+
+conf =
+(cache_server_conf
*)ap_get_module_config(parms-server-module_config,
+ cache_module);
+conf-no_expires = flag;
+conf-no_expires_set = 1;
+return NULL;
+}
static const char *set_cache_ignore_cachecontrol(cmd_parms *parms,
void *dummy, int flag)
{
@@ -942,6 +963,10 @@
AP_INIT_FLAG(CacheIgnoreNoLastMod,
set_cache_ignore_no_last_mod, NULL,
RSRC_CONF,
Ignore Responses where there is no Last Modified
Header),
+ AP_INIT_FLAG(CacheIgnoreNoExpires, set_cache_ignore_no_expires,
NULL,
+ RSRC_CONF,
+ Ignore Check on which forces expires to be present),
+
AP_INIT_FLAG(CacheIgnoreCacheControl,
set_cache_ignore_cachecontrol,
NULL,
RSRC_CONF,
Index: mod_cache.h
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.h,v
retrieving revision 1.36.2.8
diff -u -u -r1.36.2.8 mod_cache.h
--- mod_cache.h 26 Aug 2004 18:35:13 - 1.36.2.8
+++ mod_cache.h 8 Sep 2004 06:13:12 -
@@ -130,6 +130,10 @@
/** ignore the last-modified header when deciding to cache this
request */
int no_last_mod_ignore_set;
int no_last_mod_ignore;
+
+/** disable check of expires header */
+int no_expires_set;
+int no_expires;
/** ignore client's requests for uncached responses */
int ignorecachecontrol;
int ignorecachecontrol_set;
mod_cache 2 questions
ok.. so I've started playing with mod-cache again, and I noticed the following: - there is no way to cache something with query-args which doesn't return a expires tag. proposal: add a CacheIgnoreNoExpires directive so that we can cache them - Even if we add a optional function to ignore the query-args, we still check the args to see if the thing is cacheable. I'm not sure what to do about this.. maybe move some more functionality into the key-gen code... I don't know. any objections to adding yet another config option to mod-cache?
Re: [PATCH] mod_cache fixes: #6
Justin Erenkrantz wrote: --On Monday, August 2, 2004 11:44 AM -0400 Bill Stoddard [EMAIL PROTECTED] wrote: These are debug messages so not sure why they are a problem. +0 The logging code is expensive to call for every request like that as many times as it does. IMHO, there's no benefit to such a verbose log. More judicious use of logging would be fine, but what's there now is inappropriate. -- justin In mod-proxy they use a macro called 'DEBUGGING' and if-def all the really verbose log messages with that.. maybe you should apply this here?
Re: mod_cache performance
Brian Akins wrote: Justin Erenkrantz wrote: That brings it in line with mod_disk_cache in maxing out my network. Time to craft some better tests or find a faster network... -- justin I can probably help with the latter :) Can you send me details of your setup and I'll try to test later this week. we have some boxes with a GigE network as well. (set up to use flood with 10 PC's generating the load) also .. we might have 1-2 amd-64 boxes I could presuade the higher ups to use.
Re: building php5.0 as an apache module, with mysqli functionality
try raising a bug with PHP or mailing php-internals (which you didn't seem to crosspost to?) It looks like configuring with --with-mysql and --with-mysqli is probably the problem, but I'm not familiar with enough with mysqli php5 to really comment. bruce wrote: hi... this is cross posted to a number of lists as it seems to touch on all the apps... that said. i'm trying to build the PHP-5.0 version to run as an Apache mod. i need to work with mysql to get the mysqli function. i have rh8.0 linux. i'm using -httpd-2.0.50 (built from both rpm/src) -php-5.0 (building from source) -MySQL-4.1.3 (beta) tried with src/rpms.. -MySQL-Server -MySQL-devel -MySQL-shared my dir structure is pretty much the default i'm trying to build php using the following process ./configure .make clean make make install i'm trying to use the following configure ./configure --with-apxs2=/usr/sbin/apxs --with-config-file-path=/etc --with -mysql=/usr/include/mysql --with-mysqli=/usr/local/mysql/bin/mysql_config - -with-ldap --with-pgsql ./configure --with-apxs2=/usr/sbin/apxs --with-config-file-path=/etc --with -mysql=/usr/local/mysql/include --with-mysqli=/usr/local/mysql/bin/mysql_co nfig --with-ldap --with-pgsql the issue i'm having is that i can't get make portion to work without returning multiple define errors like [EMAIL PROTECTED] php-5.0.0]# make /bin/sh /usr/src/php-5.0.0/libtool --silent --preserve-dup-deps --mode=link gcc -g -O2 -prefer-pic -rpath /usr/src/php-5.0.0/libs -avoid-version -module -L/usr/local/mysql/lib -R /usr/local/mysql/lib ext/libxml/libxml.lo ext/ctype/ctype.lo ext/dom/php_dom.lo ext/dom/attr.lo ext/dom/document.lo ext/dom/domerrorhandler.lo ext/dom/domstringlist.lo ext/dom/domexception.lo ext/dom/namelist.lo ext/dom/processinginstruction.lo ext/dom/cdatasection.lo ext/dom/documentfragment.lo ext/dom/domimplementation.lo ext/dom/element.lo ext/dom/node.lo ext/dom/string_extend.lo ext/dom/characterdata.lo ext/dom/documenttype.lo ext/dom/domimplementationlist.lo ext/dom/entity.lo ext/dom/nodelist.lo ext/dom/text.lo ext/dom/comment.lo ext/dom/domconfiguration.lo ext/dom/domimplementationsource.lo ext/dom/entityreference.lo ext/dom/notation.lo ext/dom/xpath.lo ext/dom/dom_iterators.lo ext/dom/typeinfo.lo ext/dom/domerror.lo ext/dom/domlocator.lo ext/dom/namednodemap.lo ext/dom/userdatahandler.lo ext/iconv/iconv.lo ext/ldap/ldap.lo ext/mysql/php_mysql.lo ext/mysqli/mysqli.lo ext/mysqli/mysqli_api.lo ext/mysqli/mysqli_prop.lo ext/mysqli/mysqli_nonapi.lo ext/mysqli/mysqli_fe.lo ext/mysqli/mysqli_report.lo ext/mysqli/mysqli_repl.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/pgsql/pgsql.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/simplexml/simplexml.lo ext/spl/php_spl.lo ext/spl/spl_functions.lo ext/spl/spl_engine.lo ext/spl/spl_iterators.lo ext/spl/spl_array.lo ext/spl/spl_directory.lo ext/spl/spl_sxe.lo ext/sqlite/sqlite.lo ext/sqlite/sess_sqlite.lo ext/sqlite/libsqlite/src/opcodes.lo ext/sqlite/libsqlite/src/parse.lo ext/sqlite/libsqlite/src/encode.lo ext/sqlite/libsqlite/src/auth.lo ext/sqlite/libsqlite/src/btree.lo ext/sqlite/libsqlite/src/build.lo ext/sqlite/libsqlite/src/delete.lo ext/sqlite/libsqlite/src/expr.lo ext/sqlite/libsqlite/src/func.lo ext/sqlite/libsqlite/src/hash.lo ext/sqlite/libsqlite/src/insert.lo ext/sqlite/libsqlite/src/main.lo ext/sqlite/libsqlite/src/os.lo ext/sqlite/libsqlite/src/pager.lo ext/sqlite/libsqlite/src/printf.lo ext/sqlite/libsqlite/src/random.lo ext/sqlite/libsqlite/src/select.lo ext/sqlite/libsqlite/src/table.lo ext/sqlite/libsqlite/src/tokenize.lo ext/sqlite/libsqlite/src/update.lo ext/sqlite/libsqlite/src/util.lo ext/sqlite/libsqlite/src/vdbe.lo ext/sqlite/libsqlite/src/attach.lo ext/sqlite/libsqlite/src/btree_rb.lo ext/sqlite/libsqlite/src/pragma.lo ext/sqlite/libsqlite/src/vacuum.lo ext/sqlite/libsqlite/src/copy.lo ext/sqlite/libsqlite/src/vdbeaux.lo ext/sqlite/libsqlite/src/date.lo ext/sqlite/libsqlite/src/where.lo ext/sqlite/libsqlite/src/trigger.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo
The Byterange filter -- a new design -- feel free to rip it to shreds
ok, now before I start this let me say one thing, this is not for *ALL* requests, it will only work for ones which don't have content-length modifiable filters (like gzip) applied to the request, and it would be left to the webserver admin to figure out what they were, and if you could use this. ok.. at the moment when a byterange request goes to a dynamic module, the dynamic module can not use any tricks to only serve the bytes requested, it *HAS* to serve the entire content up as buckets. what I am proposing is something like: 1. the filter keeps a ordered list of range requests that the person requests. 2. it keeps state on how far it has processed in the file. thanks to knowing the length of the buckets processed so far. Q: when do the actual headers get put in.. I think they are after no? 3. it then examines the bucket + bucket length to see which range requests match this range, if some do it grabs that range (possibly splitting/copying if it meets multiple ranges) and puts it on the right bits of each range request. 4. if the top range request is finished, it passes those buckets through. 5. repeat until EOS/Sentinel, flushing the ordered list at the end. now . for part 2, we would need a method of telling the byte-range filter that the incoming brigade only has parts X, Y, Z in it. The easiest way for something like mod-proxy to do this without a API change would be for it to create a dummy bucket with the correct length, knowing that this would never be read. (yes I know it's a hack) now.. this assumes that splitting a bucket (and copying) is a zero cost operation which doesn't actually *read* the bucket, is this true for most bucket types? would this kind of thing work? --Ian
Re: 2.0.50 tarballs available for testing
Graham Leggett wrote: Joe Orton wrote: The vote is in STATUS, the patch has been shown to work independantly by one of the testers, could someone please add the last +1 so I can commit this trivial fix. Pretty please? your welcome. Regards Ian. Regards, Graham --
Re: multithreaded mpm's and mod_php
Enrico Weigelt wrote: Hi folks, does mod_php work w/ multithreaded MPMs ? cu It can, but it really depends on what libraries you link in, but yes it does work if the linked in libraries are thread safe. --Ian
Re: [PROPOSAL] Move httpd to the subversion repository
In article [EMAIL PROTECTED], Andre Malo [EMAIL PROTECTED] wrote: * Aaron Bannert [EMAIL PROTECTED] wrote: On Sat, Mar 13, 2004 at 02:04:09PM +0100, Sander Striker wrote: I hereby would like to propose that we move the HTTP Server project codebase to the Subversion repository at: http://svn.apache.org/repos/asf/. -1 This will, at least for now, raise the bar to entry for contributors. Why? nd your going to be forcing people to install some other piece of software. while this might be fine for a lot of people, some won't or can't. Some IDE's don't have SVN support yet, and some people have to deal with sysadmins who think redhat 5.2 is acceptable work environment to develop with. I'm -0.5 on the issue overall. I can't see what benefit it will give httpd overall at this stage.
Re: [Q PATCH] - mod_cache - Cache Control: no-cache/no-store
Jean-Jacques Clar wrote: These are comments copied from ap_cache_check_freshness() line 163 cache_util.c: -- * - RFC2616 14.9.4 End to end reload, Cache-Control: no-cache. no-cache in * either the request or the cached response means that we must * revalidate the request unconditionally, overriding any expiration * mechanism. It's equivalent to max-age=0,must-revalidate. * * - RFC2616 14.32 Pragma: no-cache This is treated the same as * Cache-Control: no-cache. -- RFC2616 14.9.4: _End-to-end reload_ The request includes a no-cache cache-control directive or, for compatibility with HTTP/1.0 clients, Pragma: no-cache. Field names MUST NOT be included with the no-cache directive in a request. The server MUST NOT use a cached copy when responding to such a request. 1- Cache-Control: no-cache, I don't thing the no-cache case is taking care of in ap_cache_check_freshness(). 2- _*Please comment*_: I might be wrong, but this is the way I think it should be done: +1 I don't think it should be removed either. (BTW.. it wouldn't remove it completly from the webserver anyway.. as mem_cache stores the details in a process specific manner)
Re: Save brigade and buckets
Brian Akins wrote: This may not be apache-dev related, but I do not know where else to ask it. Is it possible to save an entire bucket bridade (including it's buckets) across requests. I looked at ap_save_brigade, but I'm sure that will work. It seems that the brigades are always tied to a connection. Thanks. Hi Brian. you may want to look at how mod_mem_cache handles storing buckets for longer periods that than the request itself. regards Ian
Re: filtering huge request bodies (like 650MB files)
Cliff Woolley wrote: Which is exactly what is supposed to happen. Obviously it's not how things work at the moment, as the memory is never freed (which could probably be dealt with), but the real problem is that no data will leave the server out before it was completely read in. Yes, that would be the real problem. So somewhere there is a filter (or maybe the proxy itself) buffering the entire data stream before sending it. That is a bug. Chris... do the server's reply to you have a content-length header? if so .. this is probably what is holding up the request in the server. --Cliff
mod_mem_cache pools
hi. I was wondering if the queue/hash routines in mod-mem-cache could be reverted to using the pool based ones, instead of the malloc-based ones. and possibly change some of the object creation to pool based as well. this would leave the headers/content as malloc'd 2 reasons I can see for this: - pool's are faster than malloc - code duplication is ugly. thoughts? I know it initally was using apr's hash, but we moved it to malloc due to the increasing size problem (I think) Regards Ian
Re: cvs commit: httpd-2.0/modules/generators mod_autoindex.c
André Malo wrote: * Paul Querna [EMAIL PROTECTED] wrote: On Thu, 20 Nov 2003 07:18:55 +0100, André Malo wrote * [EMAIL PROTECTED] wrote: mod_autoindex: new directive IndexStyleSheet Hmm, why not new IndexOption? Isn't that what Indexoptions are for? You mean somthing like: IndexOpion StyleSheet:/style/mystyle.css ? More consistent with the rest of the indexoptions ;-) IndexOptions CSS=/foo/bar.css This hat btw the advantage that you can easily turn off the css for particular locations (because of the nature of IndexOptions). nd I guess you could do it with that as well. my personal preference is a seperate directive, but I'm easily swayed --Ian
[Fwd: cvs commit: httpd-test/specweb99/specweb99-2.0 mod_specweb99.c]
this commit reminds me.. weren't we going to do something similiar to this in 2.1 for the default file handler? (replace the 'stat' with a 'fstat') Will .. do you remember the whole details? it was something about putting the handle into the request_rec or something Original Message Subject: cvs commit: httpd-test/specweb99/specweb99-2.0 mod_specweb99.c Date: 19 Nov 2003 20:55:58 - From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Organization: Holsman.NET Newsgroups: server.http.apache.testing.cvs gregames2003/11/19 12:55:58 Modified:specweb99/specweb99-2.0 mod_specweb99.c Log: customadscan: use apr_file_info_get (a.k.a fstat) rather than apr_stat for about a 7% improvement in conforming connections. The box is an aging RS/6000 with a single 375 MHz ppc604e, .5G of RAM, AIX 5.2 Revision ChangesPath 1.30 +3 -3 httpd-test/specweb99/specweb99-2.0/mod_specweb99.c Index: mod_specweb99.c === RCS file: /home/cvs/httpd-test/specweb99/specweb99-2.0/mod_specweb99.c,v retrieving revision 1.29 retrieving revision 1.30 diff -u -d -b -u -r1.29 -r1.30 --- mod_specweb99.c 7 Aug 2003 21:21:57 - 1.29 +++ mod_specweb99.c 19 Nov 2003 20:55:58 - 1.30 @@ -882,11 +882,11 @@ X = apr_psprintf(r-pool, %1d, (adid % 36) / 9); Y = apr_psprintf(r-pool, %1d, adid % 9); -if ((rv = apr_stat(s, fname, APR_FINFO_SIZE, r-pool)) != APR_SUCCESS) -return; - rv = apr_file_open(f, fname, APR_READ, APR_OS_DEFAULT, r-pool); if (rv != APR_SUCCESS) +return; + +if ((rv = apr_file_info_get(s, APR_FINFO_SIZE, f)) != APR_SUCCESS) return; len = s.size;
Re: [PATCH] Add IndexStyleSheet to 2.0/2.1
Commited to the 2.1 branch. Thanks guys! Paul Querna wrote: Based on the Patch by Tyler Riddle for 1.3, these patches add an IndexStyleSheet for mod_autoindex in 2.0 and 2.1. The version for 2.1 also handles XHTML. -Paul Querna also online: http://force-elite.com/~chip/patches/httpd/mod_autoindex/
Re: caching includes parse tree
Brian Akins wrote: Any thought into parsing the results of the includes filter (offsets, etc.). In our environment, parsing the includes files is a huge performance hit. We are willing to help in any way. Hey Brian, it has been discussed before, and the two approaches is what I recall we store the parse results in a cache similiar how mod_mem_cache does it *or* run 2 mod-includes with a cache in between them. the reasoning for this is that 90% of the work assembling the page can be done once, and there is a small part which needs to be done which is user specific FWIW .. you couldn't cache the offsets of a dynamic (cgi/java/php) page as the offsets would/could change every time.
Re: consider reopening 1.3
Glenn wrote: On Sun, Nov 16, 2003 at 03:37:19PM -0500, Jim Jagielski wrote: Oh, how about my (effectively) 2-line patch which adds vhost to the error log, which I have posted to this list NO LESS THAN 6 TIMES and spaced out over the past 6 MONTHS in three different formats, using a global, expanding server_rec, and with #defines. this is not a 1.3 thing, this is a dev@ thing. your patch could have been posted for 2.0 and got the same response. (and I'm not saying you should not be pissed off, just that this is not a 1.3 thing) I have some different ideas. One is to distribute APR with 1.3 so that modules developers could incrementally move their modules to APR. why can't you just link APR into your 1.3 module? I don't think there would be any technical reason not to. Please note: I'm not in favor of implementing major changes to 1.3 that are not in-line with Apache 2.x, but am in favor of continuing bug fixes and making the eventual transition to 2.x easier. Cheers, Glenn
Re: consider reopening 1.3
Glenn wrote: On Mon, Nov 17, 2003 at 09:35:20AM +1100, Ian Holsman wrote: Glenn wrote: I have some different ideas. One is to distribute APR with 1.3 so that modules developers could incrementally move their modules to APR. why can't you just link APR into your 1.3 module? I don't think there would be any technical reason not to. Because then I would have to require that APR be installed, which is a lot harder than just requiring say apache-1.3.30. Right now, most people do something like rpm -Uvh apache-1.3.29rpm and things work. If APR were distributed with apache-1.3.30, then I could say requires apache-1.3.30 and it would not be much of a stretch to have them install it. huh??? you can get APR rpm's now. and you can build the APR independant of httpd (and have it sit in /usr/local ) and thanks to apr-config/apr-util-config it's pretty dang easy to build with them. It should be possible for many modules to keep a single codebase for both Apache 1.3 and Apache 2.x, with minimal #defines around areas that manipulate BUFF vs filters and brigades. Right now, it is not. these minimal changes is where the bugs come in. if people aren't willing to move from their apache 1.3.26, they aren't doing to upgrade to this. FWIW.. I'm -0.5 in opening up the 1.3 tree, as I see it as dead, the same as I see redhat 7.x is. I'm not saying that people don't run production systems on it, or don't rely on it, but that they are in *maintenance mode*. I don't think anyone proposes to run new sites with redhat 7.x now do they? having 2 seperate active code bases is just going to mean that 2.x is going to have less people working on it, as they are going to have to spend time fixing/maintaining all the new stuff being added/breaking in 1.3 does anyone have any stats on how long it took to migrate from 1.2.x to 1.3.x? from what I can see three reasons why people don't move * things are running fine * too hard to migrate the modules * Freebsd threading as for migrating the modules, you'll just have to bite the bullet one day, as you will when you migrate off platform X when it is EOL'd. Cheers, Glenn
Re: consider reopening 1.3
Rasmus Lerdorf wrote: I have always had the feeling that Apache2+prefork was a bit of a second-class citizen. I have tested it periodically over the past 2 years and it has never gotten anywhere close to Apache1 in performance. I ran another test of 1.3.29 vs 2.0.48-prefork just now just to make sure I wasn't blowing pure smoke here and here is what I got: Apache-1.3.29 Document Path: /bench_main.php The benchmark itself is a standard little PHP thing I use to test stuff, so it may be that our Apache2Handler for PHP is crap and we aren't smart enough to write a decent Apache2 module. I don't think it is due to you guys not having smart people rasmus, more a question of priorities, your focused on 5.0 right now, and most people are doing that. as the general impression I've seen on the php lists is that no one is using 2, no one is interested in spending the time in getting it to run faster. maybe a better test would be to re-write your benchmark program in 'c' and to the 1.3/2.0 module interface directly so you can then do remove factors like this out of the equation. rant I've never seen what use req/sec is on benchmarks. most people have thier testing machine sitting on the other end of a switched 100mbs/1G network and just bang away. what I see more interesting is: - #reqs/sec @ 30% cpu utilization, where the testing machines are on medium-low bandwidth rate limiting - possibly where the meltdown point is. ie.. how many concurrent requests can this server takes before it gets unusable (say 1sec response time) - cost of a server farm using server X to serve my business. I belive 2.0 beats 1.3 on these metrics, but like everyone here, Ihave no more energy proving/disproving which is faster.. 2.0 works for me, and thats all I really care about, not who else is using it. /rant -Rasmus
Re: ScriptLog
Cliff Woolley wrote: It's too bad you can't set the ScriptLog in a per-dir context -- that would allow an individual user (aka myself) to debug their own cgi scripts into their own error log even though there's no global ScriptLog enabled. --Cliff Hey Cliff, I guess the other one I'd like to see is rewritelogging/loglevel from inside a .htaccess file. It's a real bitch trying to debug rewrite rules inside this (and in rules inside of directory/location blocks) --I
Re: ScriptLog
Astrid Keßler wrote: Cliff wrote: On Sat, 6 Sep 2003, Astrid Keßler wrote: +1 for ScriptLog and RewriteLog(Level), although I'm not sure this is easy to implement. As I know, all log files are opend at server start. Allow directory based logging would mean to open and close log files per request. Yes, it would. But for a debug log it's a price I'm willing to accept. Just an unformed idea: allow these directives within Directory (and Location?), but not within .htaccess files. The log file could be opened as usual. Kess If you have access to the main configuration file, you can just put the scriptlog/rewritelog in there ;(
Re: Fw: apr_shm_create
Nedelcho Stanev wrote: sending this twice, since i did'n get this in mail list. may be there are some problem mailing list is probable VERY slow, thanks to all the worms to clean up your shared memory, try looking at ipcs and ipcrm. you need to remove the shared memory segments from ther via ipcrm. man ipcrm/ipcs for more info. (just be careful to remove only the ones you created ;-) ? - Original Message - From: Nedelcho Stanev To: [EMAIL PROTECTED] Sent: Friday, August 15, 2003 2:43 PM Subject: apr_shm_create Hello All, i have this problem when i use shared memory with Apache. Apache is 2.0.47, compiled on Red Hat linux 8 with kernel 2.4.18-14. Same module and same Apache on Windows work perfect, but on linux i have some problems. so ... i create shared memory block with sts = apr_shm_create(client_shm, shmem_size, MOD_MQUBE_SHMEMFILE, ctx); in initialize_module of my module. in same function i add cleanup callback with apr_pool_cleanup_register in this callbeck i do cleaning with apr_shm_destroy(client_shm); client_shm = NULL; when i stop and start apache properly all works perfect :) but if server crash, or i kill it with -9 , then in /tmp directory i still have MOD_MQUBE_SHMEMFILE file still. and this is ok, because cleanup callback is not called but when i start again apache apr_shm_create doesent work. goin in a deep, i see that in sorce of this function ( unix/shm.c) problem come from here : if ((new_m-shmid = shmget(shmkey, new_m-realsize, befor this line we have status = apr_file_open(file, filename, and this create file correctly but shmget return error - File exists so, does anyone know why this happens? :) btw , same effect is if i don't delete this file from tmp directory but, even if i delete it apache cannot allocate shared memory. decho
Re: strip rewritelog functionality per compiler option
André Malo wrote: On high-traffic production sites it is unlikely that RewriteLog will ever be used, so it may be desirable to strip the code entirely per compiler option from mod_rewrite. -0 from me. from a high-traffic site's perspecitve, I don't think we would use this option. we use the rewritelog directive for debugging sometimes, and having a common binary makes our lives a bit easier. the only thing that someone noticed over here is that the file is opened if the directive is present, which is kinda annoying. are you seeing some performance problems here? Cheers Ian FWIW.. our main webservers are usually run with light loads, to help handle flash crowds, and to have some breathing room when network/other hiccups occur in our environment This shortens the binary (here, DSO) about 10k and saves a lot of cycles (because there's still some logic there, even if RewriteLog is turned off). A patch could look like the attached one. What do you think? Objections anyone? Thanks, nd
AddOutputByType and the proxy
hey guys.
I'm trying to add the DEFALTE filter like this
Addoutputbytype DEFLATE text/html
and it works spiffy for most things.
except for reverse-proxied stuff
now before I go patching things, I was wondering if this was desired
behavior..
I'm thinking that it should be changed way down in
ap_add_output_filters_by_type
does anyone know why we change for if the request is proxied in this
function? (server/core.c)
and would this patch break anything ?
Index: core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.239
diff -u -r1.239 core.c
--- core.c 20 Jun 2003 12:53:52 - 1.239
+++ core.c 18 Jul 2003 16:59:15 -
@@ -2801,11 +2801,10 @@
conf = (core_dir_config *)ap_get_module_config(r-per_dir_config,
core_module);
-/* We can't do anything with proxy requests, no content-types or if
+/* We can't do anything with no content-types or if
* we don't have a filter configured.
*/
-if (r-proxyreq != PROXYREQ_NONE || !r-content_type ||
-!conf-ct_output_filters) {
+if ( !r-content_type || !conf-ct_output_filters) {
return;
}
[PATCH] UDP Listeners (was Re: DNS+HTTP redirection system insidean Apache module)
Very interesting Michal.
I would like to commit your UDP listener patch to apache 2.1's source tree.
(providing other people don't have any major objections)
Of course.. I would need your permission to do this first.
Regards
Ian
Michal Szymaniak wrote:
Hello,
for those of you who are interested in doing weird things in Apache,
I would like to advertise NetAirt -- a brand new redirection system inside
an Apache module. It supports both DNS- and HTTP-based redirection,
and can be used to implement Akamai-like 2-level redirection system.
And yes, it implements a UDP server inside an Apache module (although
with a few-lines patch).
As for replica selection, NetAirt can select topologically-proximal
replica servers based to network distance (AS-hops); classical stuff,
such as normal DNS operation (name-to-IP), and round-robin address
selection is also supported.
Available at: http://www.globule.org/netairt/
(src, docs, relevant papers)
Live demo: http://lotus.cs.vu.nl/
Comments welcome :-)
Enjoy,
M.
--
Michal Szymaniak | mailto:[EMAIL PROTECTED] | http://www.cs.vu.nl/~mszyman
diff -rc httpd-2.0.46-orig/include/ap_listen.h httpd-2.0.46-patched/include/ap_listen.h
*** httpd-2.0.46-orig/include/ap_listen.h Mon Feb 3 18:31:29 2003
--- httpd-2.0.46-patched/include/ap_listen.hTue Jun 17 12:30:03 2003
***
*** 65,70
--- 65,72
typedef struct ap_listen_rec ap_listen_rec;
typedef apr_status_t (*accept_function)(void **csd, ap_listen_rec *lr, apr_pool_t
*ptrans);
+ typedef apr_status_t (*socket_process_function)(void *csd, ap_listen_rec *lr,
server_rec *s, apr_pool_t *ptrans);
+ #define AP_LISTEN_REC_KEY A key to the ap_listen_rec structure NetAirt attaches to
the transaction pool
/**
* Apache's listeners record. These are used in the Multi-Processing Modules
***
*** 88,93
--- 90,99
*/
accept_function accept_func;
/**
+ * The 'process connection' function for this socket
+ */
+ socket_process_function process_func;
+ /**
* Is this socket currently active
*/
int active;
***
*** 98,103
--- 104,110
* The global list of ap_listen_rec structures
*/
AP_DECLARE_DATA extern ap_listen_rec *ap_listeners;
+ AP_DECLARE_DATA extern ap_listen_rec *ap_old_listeners;
/**
* Setup all of the defaults for the listener list
diff -rc httpd-2.0.46-orig/server/core.c httpd-2.0.46-patched/server/core.c
*** httpd-2.0.46-orig/server/core.c Tue May 13 18:01:04 2003
--- httpd-2.0.46-patched/server/core.c Tue Jun 17 12:33:32 2003
***
*** 4196,4202
apr_bucket_alloc_t *alloc)
{
apr_status_t rv;
! conn_rec *c = (conn_rec *) apr_pcalloc(ptrans, sizeof(conn_rec));
c-sbh = sbh;
(void)ap_update_child_status(c-sbh, SERVER_BUSY_READ, (request_rec *)NULL);
--- 4196,4212
apr_bucket_alloc_t *alloc)
{
apr_status_t rv;
! conn_rec *c;
! ap_listen_rec * lr = NULL;
!
! rv = apr_pool_userdata_get((void**)lr,AP_LISTEN_REC_KEY,ptrans);
! if (rv == APR_SUCCESS lr lr-process_func) {
! apr_pool_userdata_set(NULL,AP_LISTEN_REC_KEY,NULL,ptrans);
! lr-process_func(csd,lr,server,ptrans);
! return NULL;
! }
!
! c = (conn_rec *) apr_pcalloc(ptrans, sizeof(conn_rec));
c-sbh = sbh;
(void)ap_update_child_status(c-sbh, SERVER_BUSY_READ, (request_rec *)NULL);
diff -rc httpd-2.0.46-orig/server/listen.c httpd-2.0.46-patched/server/listen.c
*** httpd-2.0.46-orig/server/listen.c Mon Mar 31 06:30:52 2003
--- httpd-2.0.46-patched/server/listen.cTue Jun 17 12:36:36 2003
***
*** 72,77
--- 72,78
#include mpm_common.h
ap_listen_rec *ap_listeners = NULL;
+ ap_listen_rec *ap_old_listeners = NULL;
#if APR_HAVE_IPV6
static int default_family = APR_UNSPEC;
***
*** 79,85
static int default_family = APR_INET;
#endif
- static ap_listen_rec *old_listeners;
static int ap_listenbacklog;
static int send_buffer_size;
--- 80,85
***
*** 218,224
#else
server-accept_func = NULL;
#endif
!
return APR_SUCCESS;
}
--- 218,224
#else
server-accept_func = NULL;
#endif
! server-process_func = NULL;
return APR_SUCCESS;
}
***
*** 294,305
}
/* see if we've got an old listener for this address:port */
! for (walk = old_listeners; *walk; walk = (*walk)-next) {
sa = (*walk)-bind_addr;
/* Some listeners are not real so they will not have a bind_addr. */
if (sa) {
apr_sockaddr_port_get(oldport, sa);
! if (!strcmp(sa-hostname, addr) port == oldport) {
/* re-use existing record */
new = *walk;
*walk = new-next;
--- 294,305
}
/* see if we've
Re: mod_deflate and load
Bill Marrs wrote: Ian, I'm cross posting this to [EMAIL PROTECTED] I had been a user of Apache 1.3 and mod_gzip, but I recently upgraded to Apache 2.0 and I'm trying to use mod_deflate. I got it working fairly well, but it's causing high load and page timeouts during peak periods of operation for my site. The output I'm compressing is generated from mod_perl scripts. mod_gzip had not had this problem. It's possible that there are other factors (the whole system was upgraded), so I can't absolutely blame mod_deflate, but removing it certainly fixes the load problem. sounds like a cpu load issue. I've been dropping the DeflateCompressionLevel, which seems to help, but I'm already down to 2 and I'm still getting timeouts. I find that surprising.. the reason I do is when I put it on one of our production machines we saw a 10% in cpu load, but no timeouts (we used the hard-coded value of '1' then) what do you mean by 'timeouts'. Is there any other way I can improve the efficiency of it? first.. I would examine the cpu utilization/throughput of your box. maybe even reverting to 1.3.x/mod_gzip for a period and see if that works for you. Would changing DeflateBufferSize from 8096 to something else, help? Are there any plans to improve the efficiency of mod_deflate in the future? not directly.. most of the time spent is in zlib's library, and the standard filter routines that apache uses. I'm running Apache/2.0.46 (prefork MPM) and mod_perl-1.99_09 on Red Hat 9. Server has dual 800Mhz CPUs and 1.5GB ram. may I suggest you move to the worker MPM, I'm thinking you don't have enough ram in your machine for a pre-fork/mod-perl combo. we run with 32 threads, and it seems ok most of the time. just be careful of your 3rd party perl modules.. some may not be threadsafe. ([EMAIL PROTECTED] would be the appropiate place to ask about that) Thanks -bill regards ian
Re: Scoreboard failure: v2.0.45 won't start on RH v7.3
Hi Graham... we see this often on unclean shutdowns one of our developers (hi Blaise) over here wrote this script (we start as user 'httpd', not root BTW) just be carefull if anything else is running as the same user. # find shared memory ipcs shmipcs=$(ipcs -m | egrep -v 'Shared|shmid' | grep httpd | tr -s ' ' | \ cut -d ' ' -f 2) # find semaphore ipcs semipcs=$(ipcs -s | egrep -v 'Shared|shmid' | grep httpd | tr -s ' ' | \ cut -d ' ' -f 2) # see what's going on set -x # remove ipcs [[ -n $shmipcs ]] ipcrm shm $shmipcs [[ -n $semipcs ]] ipcrm sem $semipcs --Cheers Ian Graham Leggett wrote: Justin Erenkrantz wrote: Well, you don't need to use named-based scoreboard on Linux. Just remove the ScoreBoardFile directive. Cool, that works. :) Even though, named-based scoreboards should work. But, you need to indicate which shared memory system your APR is using. Then, you need to see where exactly the error is coming from within APR - what system call is returning it? What does the man page say for that call? No idea unfortunately, the call returns possibly errors in a number of places, but doesn't indicate which error actually triggered the problem. Will have to look at it closer in a debugger and see where it is going. It could be that your system is out of semaphores. You may want to see what ipcs reports and perhaps delete a bunch of stale ones (mod_rewrite eats semaphores for lunch). That's a pretty common occurrence. -- justin P.S. The fact that your system is complaining that the pid file is overwritten may indeed mean that there is another httpd running. This was caused by httpd shutting down uncleanly during startup. Regards, Graham
Re: mod_deflate -- File size lower bound needed?
Stephen Pierzchala wrote: All: A question for discussion: should a lower bound be set in mod_deflate? I just ran a test using the Linux Documentation Project files and found that some of the files in the test group were quite small, less that 100 bytes. When mod_deflate tackled these files, I saw a file sized increase of between 12 and 15 bytes. Doesn't sound like a lot, until maybe you start to add up all of those HTML error pages we all send. I open the floor to debate. :-) smp while this may be easy for the cases where the filter gets passed a content-length header, it may be harder for the ones where it doesn't know the size of the page before it starts compressing.. I'm cool with putting in a directive, but not sure how to write the doc's up to say that this is a 'guidance' only and that it might be ignored. we should also put in a directive to only compress when system load is below a certain level. (but we would need a apr_get_system_load() function first .. any volunteers? )
Re: Scalability of mod_cgid
Steve Sabljak wrote: Currently with apache 2.0.43 (64 bit, Solaris 8, worker mpm), under high load, we're seeing lots of connection refused to the cgi daemon in the error log. Am I right in saying mod_cgid forks new processes as they're required? Would a pre-forking cgi daemon be worth implementing? cheers, Steve Hi Steve, you may want to look at fastcgi, or perhaps even a embeded option like php or mod_perl, instead of using pure cgi for high load applications. BBCi at http://www.bbc.co.uk/
2 off-topic questions
1. does anyone know of a tool which can replay http traffic caught via tcpdump, and possibly change the hostname/ip# of the host. 2. I heard mention of a module which logs post-data (and works in apache2) can anyone remember the name. TIA Ian
Re: Modify the content after having got it
Stas Bekman wrote: Cliff Woolley wrote: On Mon, 17 Mar 2003, Greg Ames wrote: I have 'data' datas long 'lenght'. If I try to modify the data I get and to send it again inside the bucket, it doesnt work. What kind of buckets do you have before you try to modify them? You can't modify some types of buckets. You're not supposed to modify the data in ANY kind of bucket. Buckets are write-once read-many. If you want to modify the data in a bucket, you have to do a bucket read, copy the data into a new buffer, modify it, and place the new buffer into a new bucket, replacing the old bucket. Cliff, is this documented somewhere? Do you have to read-modify-replace even if you don't modify the length of the data? e.g. lowercasing all the data in the bucket? yes. always. you don't know what the backing store of the bucket is, and who else could be referecing it at the same time. (shared mem/cache/memory mapped files are examples on where you don't won't to modify the data). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
