Re: Get the actual socket of a request_rec
Hi! I totally understand your concerns regarding working directly with
the socket file descriptor.
However the module I am working on needs to cooperate with an extension in
the kernel and I would like to pass small data from the kernel to the module
by using the getsockopt API.
As soon as you have have the source code with you please post it here!
Thank you very much!
Giovanni
On Nov 29, 2007 10:32 AM, bronto [EMAIL PROTECTED] wrote:
Hello,
I don't have access o my source code right now, but the mentioned method
is not one that I used (and mine worked).
I guess, in a day or two I will be able to get to my source, and send it
here.
But to mention, are you sure you need the socket file descriptor? Since
the api is done the way, that maybe 90% of modules actually don't need
to know the socket(and use bucketsbrigades). There *are* situations
though, but think about it twice.
Regards,
Stefan
Giovanni Donelli wrote / napísal(a):
I needed to:
#define CORE_PRIVATE
Sorry about that.
Anyway, this doesn't seem to be working. I'm logging the file
descriptor of different request_rec and the result is always the same,
(this can't be, right?).
Any other way to get the actual socket of a request_rec ?
Thanks!
On Nov 22, 2007 4:10 PM, Giovanni Donelli [EMAIL PROTECTED]
wrote:
Thank you very much,
what is the core_module symbol referencing to? I can't compile
it without binding that to something.
Giovanni
On Nov 22, 2007 4:05 PM, Tamas Palagyi [EMAIL PROTECTED] wrote:
Try this:
struct apr_socket_t_internal {
apr_pool_t *pool;
int socketdes;
};
int getfd(request_rec *r) {
conn_rec *c = r-connection;
apr_socket_t *s = ap_get_module_config(c-conn_config,core_module);
struct apr_socket_t_internal *i = (struct apr_socket_t_internal *)
s;
return i-socketdes;
}
I have seen somewhere some other way to get fd tough...
Tamas
On Thu, 2007-11-22 at 15:44 +, Giovanni Donelli wrote:
Dear fellow module developer,
given a request_rec*r is there anyway to get to the actual
socket
file descriptor from which the request came in?
I have been struggling all day trying to get this info out of a
request_rec. Please help!
Thank you!
Giovanni
Nick's Book
I finally got a copy of the book. Its very good. I hope it inspires more folks to use and rely on the excellent Apache technology. Good job Nick: http://www.amazon.com/Apache-Modules-Book-Application-Development/dp/0132409674 Brian McQueen
Segmentation fault:- Inbuilt Apache 2.0.58 on Solaris 10
Hi, I am getting segmentation fault when trying to start Inbuilt Apache 2.0.58 on Solaris 10(sparc). Please suggest. Thanks CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS***
Re: mod_include -A /path (Re: Expression Parser API?)
On Thu, November 29, 2007 3:21 am, Nick Kew wrote: OK, fairy nuff I understand the shell args derivation, and that's fine by me. I'd prefer -A /foo/bar.txt 400, but I'm happy to accept your version. Aaargh... something else I struggled with was to chose just how far to take it. It would have been really easy to start with the idea add the ability to test whether URLs are accessible, and then run with it, ending up where ages later you have ultimately reengineered three quarters of mod_include, and blown any chance of a backport to 2.2. In sh syntax, the -X arg tests are typically boolean in nature, whereas -A /foo/bar.txt 400 is really string in nature. This leads onto the idea of supporting some kind of function syntax, such as status(/url), but this overloads the brackets as to now meaning either the grouping around conditional expressions (like now), or marking a parameter, and suddenly you're re-engineering the entire parser. What I don't like about the patch is the evaluation inline within the parser. The trouble is part of a bigger problem, where all the other evaluations are done inline within the parser as well, but because they are small, it passes unnoticed. I saw the problem of adding the -A option, and the problem of refactoring the parser to be generic as two separate problems, the second one being more difficult to backport. I'm updating my working version to pass in an evaluation function for shell-stuff, but there's no way that's going to make 2.2.7. So in the meantime, I attach a patch that puts the evaluation and subrequest stuff into a separate function, in preparation for taking the parser from mod_include to core at a future date. Patch attached. If you're happy with this minor reorganisation of your proposal, then you have my +1 on it. When I have some real internet access, will definitely take a look and sort it out. Regards, Graham --
Re: mod_include -A /path (Re: Expression Parser API?)
On Thu, 29 Nov 2007 12:31:52 +0200 (SAST) Graham Leggett [EMAIL PROTECTED] wrote: If you're happy with this minor reorganisation of your proposal, then you have my +1 on it. As you'll see, I've given it my +1 anyway now. Rationale: if my patch can go in now, then it can equally well happen later, and it was still too half-baked to be the final word on the subject. When I have some real internet access, will definitely take a look and sort it out. With a bit of luck we've now reached the point of singing from the same hymnsheet :-) -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: apr_ bndm? was Re: Expression Parser API?
On Thu, 29 Nov 2007 08:11:01 -0500 Akins, Brian [EMAIL PROTECTED] wrote: Needs to be against apr trunk and httpd trunk? Oh, er, um ... porting over to APR? That'd need to be raised on [EMAIL PROTECTED] I read your original post as ap_bndm, meaning httpd core. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
[PATCH] axe ancient BIG_SECURITY_HOLE message
If you should conceivably use that hack, you already know about it.
Logging spits out \t and \n literally anyway so message looks horrible.
Practically all users seeing this message just need to change User and
get on with life.
--
Born in Roswell... married an alien...
Index: os/unix/unixd.c
===
--- os/unix/unixd.c (revision 599438)
+++ os/unix/unixd.c (working copy)
@@ -169,17 +169,11 @@
unixd_config.user_name = arg;
unixd_config.user_id = ap_uname2id(arg);
-#if !defined (BIG_SECURITY_HOLE) !defined (OS2)
+#if !defined (OS2)
if (unixd_config.user_id == 0) {
-return Error:\tApache has not been designed to serve pages while\n
-\trunning as root. There are known race conditions that\n
-\twill allow any local user to read any file on the system.\n
-\tIf you still desire to serve pages as root then\n
-\tadd -DBIG_SECURITY_HOLE to the CFLAGS env variable\n
-\tand then rebuild the server.\n
-\tIt is strongly suggested that you instead modify the User\n
-\tdirective in your httpd.conf file to list a non-root\n
-\tuser.\n;
+return Error: A root user id must not be used for request processing.
+ Modify the User directive in your httpd.conf file to list a
+ non-root user.;
}
#endif
Re: apr_ bndm? was Re: Expression Parser API?
On 11/28/07 8:27 PM, Nick Kew [EMAIL PROTECTED] wrote: I haven't looked at that specifically, but I think it likely there's a good case for it. Are you volunteering to hack up a patch? Sure. Why not. Needs to be against apr trunk and httpd trunk? -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: apr_ bndm? was Re: Expression Parser API?
On 11/29/07 8:23 AM, Nick Kew [EMAIL PROTECTED] wrote: Oh, er, um ... porting over to APR? That'd need to be raised on [EMAIL PROTECTED] I read your original post as ap_bndm, meaning httpd core. I can just do ap_bndm. Just to keep it on this list... Any particular place we are sticking util stuff in the tree? -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: [PATCH] axe ancient BIG_SECURITY_HOLE message
On Nov 29, 2007 8:36 AM, Jeff Trawick [EMAIL PROTECTED] wrote: If you should conceivably use that hack, you already know about it. Logging spits out \t and \n literally anyway so message looks horrible. Practically all users seeing this message just need to change User and get on with life. patch was broken ;) this line must be left unchanged so that BIG_SECURITY_HOLE still works for those few -#if !defined (BIG_SECURITY_HOLE) !defined (OS2) +#if !defined (OS2)
Re: svn commit: r599385 - in /httpd/httpd/trunk: ./ modules/ssl/
On 11/29/2007 12:18 PM, [EMAIL PROTECTED] wrote:
Author: jorton
Date: Thu Nov 29 03:18:40 2007
New Revision: 599385
URL: http://svn.apache.org/viewvc?rev=599385view=rev
Log:
mod_ssl: Add support for OCSP validation of client certificates:
* modules/ssl/ssl_engine_config.c (modssl_ctx_init,
modssl_ctx_cfg_merge): Initialize and merge OCSP config options.
(ssl_cmd_SSLOCSPOverrideResponder, ssl_cmd_SSLOCSPDefaultResponder,
ssl_cmd_SSLOCSPEnable): Add functions.
* modules/ssl/mod_ssl.c (ssl_config_cmds): Add config options.
* modules/ssl/ssl_private.h: Add prototypes, config options to
modssl_ctx_t.
* modules/ssl/ssl_util_ocsp.c: New file, utility interface for
dispatching OCSP requests.
* modules/ssl/ssl_engine_ocsp.c: New file, interface for performing
OCSP validation.
* modules/ssl/ssl_engine_kernel.c (ssl_callback_SSLVerify): Perform
OCSP validation if configured, and the cert is so-far verified to be
trusted. Fail if OCSP validation is configured an the optional-no-ca
check tripped.
* modules/ssl/config.m4: Check for OCSP support, build new files.
* modules/ssl/mod_ssl.dsp: Build new files.
* modules/ssl/ssl_toolkit_compat.h: Include headers for OCSP
interfaces.
PR: 41123
Submitted by: Marc Stern marc.stern approach.be, Joe Orton
Reviewed by: Steve Henson steve openssl.org
Added:
httpd/httpd/trunk/modules/ssl/ssl_engine_ocsp.c (with props)
httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c (with props)
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/modules/ssl/config.m4
httpd/httpd/trunk/modules/ssl/mod_ssl.c
httpd/httpd/trunk/modules/ssl/mod_ssl.dsp
httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
httpd/httpd/trunk/modules/ssl/ssl_private.h
httpd/httpd/trunk/modules/ssl/ssl_toolkit_compat.h
Modified: httpd/httpd/trunk/CHANGES
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=599385r1=599384r2=599385view=diff
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Thu Nov 29 03:18:40 2007
@@ -2,6 +2,9 @@
Changes with Apache 2.3.0
[ When backported to 2.2.x, remove entry from this file ]
+ *) mod_ssl: Add support for OCSP validation of client certificates.
+ PR 41123. [Marc Stern marc.stern approach.be, Joe Orton]
+
Shouldn't we add Steve to this? As far as I followed the discussion in Bugzilla
he contributed very valuable points and we have credited people for less in the
past :-).
Added: httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c?rev=599385view=auto
==
--- httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c (added)
+++ httpd/httpd/trunk/modules/ssl/ssl_util_ocsp.c Thu Nov 29 03:18:40 2007
@@ -0,0 +1,299 @@
+/* Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* This file implements an OCSP client including a toy HTTP/1.0
+ * client. Once httpd depends on a real HTTP client library, most of
+ * this can be thrown away. */
+
+#include ssl_private.h
+
+#ifdef HAVE_OCSP
+
+#include apr_buckets.h
+#include apr_uri.h
+
+/* Serialize an OCSP request which will be sent to the responder at
+ * given URI to a memory BIO object, which is returned. */
+static BIO *serialize_request(OCSP_REQUEST *req, const apr_uri_t *uri)
+{
+BIO *bio;
+int len;
+
+len = i2d_OCSP_REQUEST(req, NULL);
+
+bio = BIO_new(BIO_s_mem());
+
+BIO_printf(bio, POST %s%s HTTP/1.0\r\n
+ Host: %s:%d\r\n
+ Content-Length: %d\r\n
+ \r\n,
+ uri-path, uri-query ? uri-query : ,
+ uri-hostname, uri-port, len);
+
+if (i2d_OCSP_REQUEST_bio(bio, req) != 1) {
+BIO_free(bio);
+return NULL;
+}
+
+return bio;
+}
+
+/* Send the OCSP request serialized into BIO 'request' to the
+ * responder at given server given by URI. Returns socket object or
+ *
mod_ssl OCSP questions
Taking this discussion out of bugzilla. As implemented currently the OCSP validation is working like this: 1) trusted store T initialized with root certs configured via SSLCA* 2) foreach cert in chain from (root...client certificate): a) verify cert is signed by trusted cert (or, is transitively so) b) if so, perform OCSP validation on cert as follows: i) pick a responder, exchange OCSP messages ii) verify signature of OCSP response against certs in trusted store T I'm not familiar with how OCSP is typically deployed; my questions are: a) is it acceptable to assume that the same set of trusted certs is used to verify the signature of the OCSP response as is used to verify the client cert itself? Or do these need to be separately configurable? b) does it really make sense to be doing OCSP validation individually on each cert in the peer's cert chain? Marc mentioned an issue with a compromised intermediary cert; but I want to be sure I understand this properly. Can someone explain the exact threat model which checking the whole chain would be necessary for? c) Steve mentioned some responders don't accept requests with nonces. What is a sane default? Send nonces (more secure), or not (better interop). From reading the RFC it looks like mod_ssl should also be checking the validity times from the OCSP response, which would help, I guess. Regards, joe
Re: svn commit: r599385 - in /httpd/httpd/trunk: ./ modules/ssl/
On Thu, Nov 29, 2007 at 09:02:43PM +0100, Ruediger Pluem wrote:
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Thu Nov 29 03:18:40 2007
@@ -2,6 +2,9 @@
Changes with Apache 2.3.0
[ When backported to 2.2.x, remove entry from this file ]
+ *) mod_ssl: Add support for OCSP validation of client certificates.
+ PR 41123. [Marc Stern marc.stern approach.be, Joe Orton]
+
Shouldn't we add Steve to this? As far as I followed the discussion in
Bugzilla he contributed very valuable points and we have credited
people for less in the past :-).
Discussing this stuff makes me slightly uncomfortable, but I try to
follow a strict rule: credit in CHANGES exactly the set of people who
contributed actual lines of code. Steve was credited in the commit
messages as a reviewer. Such review is invaluable, no argument at all
:)
...
+/* Send the OCSP request serialized into BIO 'request' to the
+ * responder at given server given by URI. Returns socket object or
+ * NULL on error. */
+static apr_socket_t *send_request(BIO *request, const apr_uri_t *uri,
+ conn_rec *c, apr_pool_t *p)
+{
+apr_status_t rv;
+apr_sockaddr_t *sa;
+apr_socket_t *sd;
+char buf[HUGE_STRING_LEN];
Is it really a good idea to store this on the stack? Shouldn't we allocate
this from the pool?
Hmmm, shrug - stack is cheaper than heap.
...
+while ((len = BIO_read(request, buf, sizeof buf)) 0) {
+char *wbuf = buf;
+apr_size_t remain = len;
+
+do {
+apr_size_t wlen = remain;
+
+rv = apr_socket_send(sd, wbuf, wlen);
+wbuf += remain;
+remain -= wlen;
+} while (rv == APR_SUCCESS remain 0);
Why do we need remain here and do not use len directly?
Really only to make the types match; len is an int but wlen must be an
apr_size_t.
...
+count = 0;
+while ((line = get_line(tmpbb, bb, c, p)) != NULL line[0]
+++count MAX_HEADERS) {
+ap_log_cerror(APLOG_MARK, APLOG_DEBUG, 0, c,
+ OCSP response header: %s, line);
+}
Why don't we exit with an error message if count MAX_HEADERS?
Good catch, will fix.
...
+apr_brigade_destroy(bb);
+apr_brigade_destroy(tmpbb);
We miss to destroy the brigades in the cases above where we return NULL.
They are allocated out of the pool, so it Shouldn't Matter (TM).
Thanks for the review!
joe
Re: mod_ssl OCSP questions
Joe Orton wrote: Taking this discussion out of bugzilla. As implemented currently the OCSP validation is working like this: 1) trusted store T initialized with root certs configured via SSLCA* 2) foreach cert in chain from (root...client certificate): a) verify cert is signed by trusted cert (or, is transitively so) b) if so, perform OCSP validation on cert as follows: i) pick a responder, exchange OCSP messages ii) verify signature of OCSP response against certs in trusted store T I'm not familiar with how OCSP is typically deployed; my questions are: a) is it acceptable to assume that the same set of trusted certs is used to verify the signature of the OCSP response as is used to verify the client cert itself? Or do these need to be separately configurable? There are several techniques used. 1. Sign responses using the key from the CA that issued the cert(s) being checked. This isn't often done because it would involve the responder having access to a certificate signing key. 2. Sign responses using a special certificate signed by the CA that issued the cert(s) being checked. This is by far the most common. It avoids the problems of 1 and responses can be verified without additional configuration. 3. Sign responses using a key which is trusted by some out of band means. This covers cases where (for example) a locate OCSP responder is used to sign responses for a site or a responder will handle multiple unconnected CAs. OpenSSL supports #1 and #2 directly so these should be automatic if the OpenSSL OCSP API has been used correctly. A limited form of #3 is implemented in OpenSSL. A generalised version might be more appropriate in some circumstances but would need additional configuration options to implement. b) does it really make sense to be doing OCSP validation individually on each cert in the peer's cert chain? Marc mentioned an issue with a compromised intermediary cert; but I want to be sure I understand this properly. Can someone explain the exact threat model which checking the whole chain would be necessary for? If the CA key is compromised (e.g. used once maliciously) then it can be used to issue an OCSP responder certificate under #2 above. That could be used in a bogus responder. Some security policies don't consider this likely enough to check the whole chain and just check the EE cert which is much more likely to be revoked. I'd say making this configurable would be the best option. c) Steve mentioned some responders don't accept requests with nonces. What is a sane default? Send nonces (more secure), or not (better interop). From reading the RFC it looks like mod_ssl should also be checking the validity times from the OCSP response, which would help, I guess. I'll check how we are using the API. There are some OCSP helper functions in OpenSSL which check the appropriate times and allow a configurable skew for cases where clocks are inaccurately set. How much skew to allow in practice may again depend on local policy. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage.
Re: svn commit: r599385 - in /httpd/httpd/trunk: ./ modules/ssl/
On 11/29/2007 10:03 PM, Joe Orton wrote:
On Thu, Nov 29, 2007 at 09:02:43PM +0100, Ruediger Pluem wrote:
==
--- httpd/httpd/trunk/CHANGES [utf-8] (original)
+++ httpd/httpd/trunk/CHANGES [utf-8] Thu Nov 29 03:18:40 2007
@@ -2,6 +2,9 @@
Changes with Apache 2.3.0
[ When backported to 2.2.x, remove entry from this file ]
+ *) mod_ssl: Add support for OCSP validation of client certificates.
+ PR 41123. [Marc Stern marc.stern approach.be, Joe Orton]
+
Shouldn't we add Steve to this? As far as I followed the discussion in
Bugzilla he contributed very valuable points and we have credited
people for less in the past :-).
Discussing this stuff makes me slightly uncomfortable, but I try to
follow a strict rule: credit in CHANGES exactly the set of people who
contributed actual lines of code. Steve was credited in the commit
messages as a reviewer. Such review is invaluable, no argument at all
:)
This rule is fine with me. I guess everybody has its own ruleset here which
might be slightly different.
I guess Steve is famous enough such that he can live without a CHANGES entry
and only a commit message :).
...
+/* Send the OCSP request serialized into BIO 'request' to the
+ * responder at given server given by URI. Returns socket object or
+ * NULL on error. */
+static apr_socket_t *send_request(BIO *request, const apr_uri_t *uri,
+ conn_rec *c, apr_pool_t *p)
+{
+apr_status_t rv;
+apr_sockaddr_t *sa;
+apr_socket_t *sd;
+char buf[HUGE_STRING_LEN];
Is it really a good idea to store this on the stack? Shouldn't we allocate
this from the pool?
Hmmm, shrug - stack is cheaper than heap.
Just thought of platforms with small default stack sizes.
So lets stick to it until someone reports problems.
...
+while ((len = BIO_read(request, buf, sizeof buf)) 0) {
+char *wbuf = buf;
+apr_size_t remain = len;
+
+do {
+apr_size_t wlen = remain;
+
+rv = apr_socket_send(sd, wbuf, wlen);
+wbuf += remain;
+remain -= wlen;
+} while (rv == APR_SUCCESS remain 0);
Why do we need remain here and do not use len directly?
Really only to make the types match; len is an int but wlen must be an
apr_size_t.
Thanks for explaining.
...
+apr_brigade_destroy(bb);
+apr_brigade_destroy(tmpbb);
We miss to destroy the brigades in the cases above where we return NULL.
They are allocated out of the pool, so it Shouldn't Matter (TM).
Ok. They are taken from the newly created vpool. So it shouldn't really matter.
Regards
Rüdiger
Re: svn commit: r599385 - in /httpd/httpd/trunk: ./ modules/ssl/
Ruediger Pluem wrote: On 11/29/2007 10:03 PM, Joe Orton wrote: On Thu, Nov 29, 2007 at 09:02:43PM +0100, Ruediger Pluem wrote: == --- httpd/httpd/trunk/CHANGES [utf-8] (original) +++ httpd/httpd/trunk/CHANGES [utf-8] Thu Nov 29 03:18:40 2007 @@ -2,6 +2,9 @@ Changes with Apache 2.3.0 [ When backported to 2.2.x, remove entry from this file ] + *) mod_ssl: Add support for OCSP validation of client certificates. + PR 41123. [Marc Stern marc.stern approach.be, Joe Orton] + Shouldn't we add Steve to this? As far as I followed the discussion in Bugzilla he contributed very valuable points and we have credited people for less in the past :-). Discussing this stuff makes me slightly uncomfortable, but I try to follow a strict rule: credit in CHANGES exactly the set of people who contributed actual lines of code. Steve was credited in the commit messages as a reviewer. Such review is invaluable, no argument at all :) This rule is fine with me. I guess everybody has its own ruleset here which might be slightly different. I guess Steve is famous enough such that he can live without a CHANGES entry and only a commit message :). Can one be famous enough? ;-) Don't mind at all either way to be honest. I haven't had the opportunity to study mod_ssl much until now and I hope to do considerably more in future to at least merit the occasional CHANGES credit. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage.
randomized request for apache benchmark
For the primarily web application is no longer static. Considering factors like cache, instruction prediction, I suppose randomized request is need to avoid possible bias in benchmark. So I wanna proposal a patch for this. Any suggestion? -- This is kAbY, after University of Electronic Science and Technology of China, where we intend to a creative work.
Re: randomized request for apache benchmark
kaby wrote: For the primarily web application is no longer static. Considering factors like cache, instruction prediction, I suppose randomized request is need to avoid possible bias in benchmark. So I wanna proposal a patch for this. Any suggestion? ab.c isn't the place for such work, and you are absolutely right (modern architectures are incredibly good at doing stupidly repetitive tasks efficiently, and this doesn't mirror the real world). Would you take a look at http://svn.apache.org/repos/asf/httpd/test/trunk/flood/ which is already moving in the direction of flexibility you seek, and is actively soliciting new ideas and patches? Bill
how to append to strings...
I am rewriting part of my module to use expat, a parse I have used in years gone by. I know it, I sort of even like it and my XML is pretty simple, except... I need to extract one text element. I know that even though the text I need is in one continues line in the XML, expat can and at times will call my handler multiple times for that one continues string. The question is: What is the correct way to append all the pieces of XML that I am going to get from expat into one string? I recall reading somewhere that Apache has a really slick way of being able to break up a string into pieces so that one can quickly inject something in the middle without having to move any memory around. What ever it is called, I am thinking that is the right solution: build an array of the strings and use this feature of apache to put them together. Am I on the right track? If so, can someone enlighten me as to what exactly I should be looking up in my Writing Apache Modules with Perl and C book? Sam
