Re: Intercepting HTTP 301/302 redirects
On 02/29/2012 07:46 PM, Swaminathan Bhaskar wrote:
Thanks for the quick response Joe. Just to make sure, here is what I did:
IfModule mod_myfilter.c
Location /
SetOutputFilter myfilter
/Location
/IfModule
and the code
#include stdio.h
#include httpd.h
#include http_protocol.h
#include http_config.h
#include util_filter.h
#define MY_FILTER_NAME myfilter
static int my_output_filter(ap_filter_t *f, apr_bucket_brigade *bb)
{
fprintf(stderr, mod_myfilter: status = %d, status-line = %s\n,
f-r-status, f-r-status_line);
ap_pass_brigade(f-next, bb);
return APR_SUCCESS;
}
static void my_filter_hooks(apr_pool_t *pool)
{
ap_register_output_filter(MY_FILTER_NAME, my_output_filter, NULL,
AP_FTYPE_RESOURCE);
fprintf(stderr, mod_myfilter: registered my_output_filter\n);
}
module AP_MODULE_DECLARE_DATA myfilter_module = {
STANDARD20_MODULE_STUFF,
NULL,
NULL,
NULL,
NULL,
NULL,
my_filter_hooks
};
I setup an intentional redirect for testing
Redirect 301 /red.htm http://localhost/green.htm
When I try http://localhost/, should I not see the output from myfilter ?
Maybe. Remember, errors don't go through the same outputs as regular
responses. If you want to filter the results of anything outside of the
standard 2xx HTTP responses, you have to insert an error filter as well,
hence my reference to ap_hook_insert_error_filter(). As an example
(borrowed from some of my source and modified for yours) :
static void insert_my_output_error_filter(request_rec *r) {
ap_add_output_filter(MY_FILTER_NAME,NULL,r,r-connection);
}
static void my_filter_hooks(apr_pool_t *p) {
ap_hook_insert_error_filter(insert_my_output_error_filter, NULL,
NULL, APR_HOOK_LAST);
ap_register_output_filter(MY_FILTER_NAME,my_output_filter,NULL,AP_FTYPE_RESOURCE);
};
Again, output filters and errors do not coincide. If you want to catch
both, you have to hook both. (Same thing for r-headers_out and
r-err_headers_out - r-headers_out won't make it into r-err_headers_out).
Joe
--
http://www.silverhawk.net
Re: Intercepting HTTP 301/302 redirects
Ahh - Finally, I was able to get it working. Thanks for the pointer.
Here is the code snippet:
#include stdio.h
#include httpd.h
#include http_protocol.h
#include http_config.h
#include http_log.h
#include util_filter.h
#define MY_FILTER_NAME myfilter
static void insert_myfilter(request_rec *req)
{
ap_add_output_filter(MY_FILTER_NAME, NULL, req, req-connection);
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, req-server, mod_myfilter:
inserted myfilter);
}
static int my_output_filter(ap_filter_t *f, apr_bucket_brigade *bb)
{
if (f-r-status_line != NULL) {
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, f-r-server,
mod_myfilter: status = %d, status-line = %s, f-r-status,
f-r-status_line);
}
else {
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, f-r-server,
mod_myfilter: status = %d, f-r-status);
}
ap_pass_brigade(f-next, bb);
return APR_SUCCESS;
}
static void my_filter_hooks(apr_pool_t *pool)
{
ap_register_output_filter(MY_FILTER_NAME, my_output_filter, NULL,
AP_FTYPE_RESOURCE);
ap_hook_insert_filter(insert_myfilter, NULL, NULL, APR_HOOK_LAST);
ap_hook_insert_error_filter(insert_myfilter, NULL, NULL, APR_HOOK_LAST);
fprintf(stderr, mod_myfilter: registered my_output_filter\n);
}
module AP_MODULE_DECLARE_DATA myfilter_module = {
STANDARD20_MODULE_STUFF,
NULL,
NULL,
NULL,
NULL,
NULL,
my_filter_hooks
};
Rgds
Bhaskar
--
View this message in context:
http://old.nabble.com/Intercepting-HTTP-301-302-redirects-tp33418215p33422513.html
Sent from the Apache HTTP Server - Module Writers mailing list archive at
Nabble.com.
Re: Intercepting HTTP 301/302 redirects
Congrats! Welcome to the world of filters!
On 03/01/2012 09:37 AM, Swaminathan Bhaskar wrote:
Ahh - Finally, I was able to get it working. Thanks for the pointer.
Here is the code snippet:
#includestdio.h
#includehttpd.h
#includehttp_protocol.h
#includehttp_config.h
#includehttp_log.h
#includeutil_filter.h
#define MY_FILTER_NAME myfilter
static void insert_myfilter(request_rec *req)
{
ap_add_output_filter(MY_FILTER_NAME, NULL, req, req-connection);
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, req-server, mod_myfilter:
inserted myfilter);
}
static int my_output_filter(ap_filter_t *f, apr_bucket_brigade *bb)
{
if (f-r-status_line != NULL) {
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, f-r-server,
mod_myfilter: status = %d, status-line = %s, f-r-status,
f-r-status_line);
}
else {
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, f-r-server,
mod_myfilter: status = %d, f-r-status);
}
ap_pass_brigade(f-next, bb);
return APR_SUCCESS;
}
static void my_filter_hooks(apr_pool_t *pool)
{
ap_register_output_filter(MY_FILTER_NAME, my_output_filter, NULL,
AP_FTYPE_RESOURCE);
ap_hook_insert_filter(insert_myfilter, NULL, NULL, APR_HOOK_LAST);
ap_hook_insert_error_filter(insert_myfilter, NULL, NULL, APR_HOOK_LAST);
fprintf(stderr, mod_myfilter: registered my_output_filter\n);
}
module AP_MODULE_DECLARE_DATA myfilter_module = {
STANDARD20_MODULE_STUFF,
NULL,
NULL,
NULL,
NULL,
NULL,
my_filter_hooks
};
Rgds
Bhaskar
Re: thread ID
On Thu, Mar 1, 2012 at 17:29, sorin.manola...@orange.com wrote: Hello, I would need a memory buffer associated per worker thread (in the worker MPM) or to each process (in the prefork MPM). In order to do that, I would need a map thread-buffer. So, I would need a sort of thread ID/key/handle that stays the same during the lifetime of the thread and no two threads in the same process can have the same ID/key/handle. What is the most portable way to get this thread ID? I thought of r-connection-id. It works but it is not very portable as it is not guaranteed that two connections created by the same thread will have the same id. They do for now. If r-connection-sbh was not opaque it would be great, because sbh-thread_num would be exactly what I need. I could also use pthread_self. It works too but, in general, it is not guaranteed that the worker threads are pthreads. Thank you for your help. Sorin What about apr_os_thread_current()? It returns a opaque value that's a pthread_t on Unices and a pseudo-HANDLE on Windows. Read this[1] to understand what that means. As a recovering standards lawyer I should probably point out that pthread_t is an opaque type that's not guaranteed to be convertible to a numeric value (or to anything, really). That said, I've never seen a pthreads implementation where that wasn't the case. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms683182%28v=vs.85%29.aspx
Re: thread ID
On 03/02/12 00:21, Ben Noordhuis wrote: On Thu, Mar 1, 2012 at 17:29,sorin.manola...@orange.com wrote: Hello, I would need a memory buffer associated per worker thread (in the worker MPM) or to each process (in the prefork MPM). In order to do that, I would need a map thread-buffer. So, I would need a sort of thread ID/key/handle that stays the same during the lifetime of the thread and no two threads in the same process can have the same ID/key/handle. What is the most portable way to get this thread ID? I thought of r-connection-id. It works but it is not very portable as it is not guaranteed that two connections created by the same thread will have the same id. They do for now. If r-connection-sbh was not opaque it would be great, because sbh-thread_num would be exactly what I need. I could also use pthread_self. It works too but, in general, it is not guaranteed that the worker threads are pthreads. Thank you for your help. Sorin What about apr_os_thread_current()? It returns a opaque value that's a pthread_t on Unices and a pseudo-HANDLE on Windows. Read this[1] to understand what that means. As a recovering standards lawyer I should probably point out that pthread_t is an opaque type that's not guaranteed to be convertible to a numeric value (or to anything, really). That said, I've never seen a pthreads implementation where that wasn't the case. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms683182%28v=vs.85%29.aspx Thank you, it's what I need. Sorin
How to read PHP session in module
Hello, I want to read PHP session in my private module. PHP session id is in PHPSESSID cookie but I want to read the contents of PHP session in my module. Please let me know if you have any suggestions. Thank you in advance. Yokota Sakuko
Still #ifdef WIN64 in APR
In APR 1.4.6 there is still a typo in the statements, causes crashes HTTPD in eg. setting on logging in mod_rewrite. In shm.c and apr.hw #ifdef WIN64 Sould be: #ifdef _WIN64 Steffen
Re: [RFC] try to solidify feature adoption criteria
On Wed, Feb 29, 2012 at 12:57 PM, Jeff Trawick traw...@gmail.com wrote: New features are a natural part of the software life-cycle, but they One obvious alternative is to simply document that new features of any magnitude can be added to trunk at will by any committer. Presence in a stable branch is subject to a level of documentation considered acceptable to other committers. Merging new features to an existing stable branch is subject to commit rules for that branch. --/-- Or just drop the documentation requirement. --/-- Not writing down any group think on this invites future conflict.
Re: Still #ifdef WIN64 in APR
On Thu, Mar 1, 2012 at 6:15 AM, Steffen i...@apachelounge.com wrote: In APR 1.4.6 there is still a typo in the statements, causes crashes HTTPD in eg. setting on logging in mod_rewrite. In shm.c and apr.hw #ifdef WIN64 Sould be: #ifdef _WIN64 Steffen Does this work for you? http://svn.apache.org/viewvc?view=revisionrevision=1295535 (I'll move the fix back to 1.5 and 1.4 branches and retarget the bug to apr.) -- Born in Roswell... married an alien...
Re: Still #ifdef WIN64 in APR
Does this work for you? http://svn.apache.org/viewvc?view=revisionrevision=1295535 (I'll move the fix back to 1.5 and 1.4 branches and retarget the bug to apr.) Looks right here given the report and stackoverflow post.
Re: Still #ifdef WIN64 in APR
Anindya supplies already some time a build with the change, as far as I know, no issues reported. -Original Message- From: Jeff Trawick Sent: Thursday, March 01, 2012 1:30 PM Newsgroups: gmane.comp.apache.devel To: dev@httpd.apache.org ; APR Developer List Subject: Re: Still #ifdef WIN64 in APR On Thu, Mar 1, 2012 at 6:15 AM, Steffen i...@apachelounge.com wrote: In APR 1.4.6 there is still a typo in the statements, causes crashes HTTPD in eg. setting on logging in mod_rewrite. In shm.c and apr.hw #ifdef WIN64 Sould be: #ifdef _WIN64 Steffen Does this work for you? http://svn.apache.org/viewvc?view=revisionrevision=1295535 (I'll move the fix back to 1.5 and 1.4 branches and retarget the bug to apr.) -- Born in Roswell... married an alien...
Re: Technical reasons for -1 votes (?)
On 2/29/2012 6:25 PM, Roy T. Fielding wrote: On Feb 29, 2012, at 9:42 AM, William A. Rowe Jr. wrote: Let's take Roy's position on the attached vote discussion, it's relevant. These new modules are certainly additions/deletions to httpd. Yes, but they are modules. Hence, their mere existence in our tree is not a technical reason to exclude them. We have a modular architecture so that people who don't want a module don't have to build it. In fact, it was exactly this type of argument in 1995 that caused rst to focus on creating a modular architecture. Ok, so to clarify, you are reversing your answer to Joe? The LDAP changes were a change to a module. Not an httpd-wide API, just a module. So you are saying that your comment to Joe, The API was moved to *this* project and all of the names were changed. It is, effectively, a new public API for this project. was a misinformed statement (as it moved the ldap code into mod_ldap and not into the core API). That veto was unjustified? Or rather, had we not exported a single symbol, then the veto was unjustified? If there were dependencies or license conditions brought in that somehow harmed the server without the module being active, then that would be a technical objection. There was no such case for the ldap change, so you are saying that specific veto was unjustified, right? Anyways, all of this is distraction, let's drill in further to your analysis; Traditionally, we have allowed any module that has at least one willing volunteer committer to maintain it. And I agree with Jim, none of the subprojects have been as successful as just placing the code in the main tree. Allowed it by... voting to accept it, right? I accept that all of my colleagues have different rationals for their +/- votes. Right now, just about 3% of the committee are willing to entertain these module additions to httpd trunk and 1.5% are against adding these to trunk. I chalk this up to burnout, 2.4 was very complex to release and people know their +1 votes are commitments and alter the httpd tarball for better or worse. As Jim points out, The fact is that once a project lives under the main tree, it's part of our shared project is dead to right. Jim alone is voting with minfrin to support these living in that shared tree, and only I vote that we don't, at this time, until there are more committers who are willing to share Jim's position. If there was a vote to add this module to core, that would be lovely, we could vote on it. Sadly, minfrin offered no such vote, and whatever your conclusion on the 'better course' - it was not voted on, and you hadn't expressed a vote to adopt it in either case. I have no idea why mod_fcgi is in a subproject. mod_ftp is there because it isn't an HTTP server. mod_aspdotnet had all sorts of licensing issues that I never quite figured out. Nonsequitor, if we want to launch into a discussion of subprojects vs. modules, that's great. That wasn't the conversation minfrin started, and that's why I have a VETO on the commit. Correct the mis-execution by conforming to the vote he held, or correct the vote instead. I've VETOED a commit which is something other than what was voted on because the project did not consent to his action. If there are two other committers who will vote with Jim for this project to accept one or more of these modules into trunk (rather than subproject), and someone will finish the ip-clearance, I'm great with that. If none of that happens I will revert this mess. I see no reason not to commit mod_firehose, though I haven't had a chance to look at the code myself. mod_firehose is already [erroniously] committed without ip-clearance. Only Jim agrees with minfrin that it belongs in trunk. If YOU want to vote for it to be in trunk, do that. So far, it was accepted by this project only as an additional subproject. Only you and Jim are defending this addition without ip-clearance. Perhaps you are signing up to do that ip-clearance, since it doesn't seem to be coming from the committer. I've voted against mod_policy and mod_combine until this mess is resolved. With sufficient +1's I would have withdrawn all objections, but right now I smell a code dump, and see nobody but Jim disagreeing with me. Nor am I willing to respect a veto war based on the impact of past vetos. No, it's not a veto war. Only Jim has volunteered to maintain this code (or agreed to help minfrin do so). Right now minfrin blocks correcting mod_ldap, insists it's his project to finish his way, which hurts this project. So his assurance that he should my intention is to continue to develop and support this rings hollow. That is the ONLY relationship to the other veto I had quoted your opinion on, other than to point out that vetos are legitimate. Any assurance that he should be a sole maintainer of not one but three+ more httpd module additions seems foolish. Now, if you'll excuse me, I have at least two other
Re: Technical reasons for -1 votes (?)
On Mar 1, 2012 12:20 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: ... If there are two other committers who will vote with Jim for this project to accept one or more of these modules into trunk (rather than subproject), and someone will finish the ip-clearance, I'm great with that. If none of that happens I will revert this mess. I support Jim. +1
[RE-VOTE] adoption of mod_firehose MODULE
Let's simply reset this whole mess. A proposal to adopt mod_firehose is attached. [ ] Option 1: adopt as trunk module [ ] Option 2: adopt only as subproject [ ] Option 3: do not adopt [Prior to this vote, option 2 had previously passed with minfrin, issac, sctemme, jim in support. Subsequently, wrowe endorsed option 2, while minfrin, jim introduced option 1. Please vote.] On 12/13/2011 9:19 AM, Graham Leggett wrote: Hi all, I have concluded negotiation with the BBC to open source some httpd modules that I wrote under the AL, and the BBC have very kindly agreed to donate the code to the ASF[1], which I believe would fit well as subprojects of httpd, and would like to know whether httpd would accept these. To be clear, this isn't a code dump, my intention is to continue to develop and support this moving forward, and hopefully expand the community around them. - mod_firehose: tcpdump for httpd Based originally on mod_dumpio.c, mod_firehose is an httpd filter that writes the contents of a request and/or a response to a file or pipe in such a way that the requests can be reconstructed later using a second dedicated tool called firehose. It was initially developed to help debug restful services that were secured with client certificates and therefore opaque to other tools like tcpdump or tcpflow, but was then subsequently used to record dirty traffic for subsequent replay for the purposes of testing. The module and the corresponding firehose demultiplexer was used to uncover some of the more tricky bugs in mod_cache, as well as protocol inconsistencies in backend services, and would prove very useful to anyone deploying restful services. We have also intended it to be used to create a dark live environment, where live traffic can be split off and diverted to a staging environment to test whether a software update works correctly. The code is currently packaged as an RPM, wrapped in autotools, and a snapshot is available here: http://people.apache.org/~minfrin/bbc-donated/mod_firehose/ http://people.apache.org/~minfrin/bbc-donated/firehose/ The corresponding README documenting in more detail is here: http://people.apache.org/~minfrin/bbc-donated/mod_firehose/README The code itself is here: http://people.apache.org/~minfrin/bbc-donated/mod_firehose/mod_firehose.c http://people.apache.org/~minfrin/bbc-donated/firehose/firehose.c Obviously the expectation is for the documentation to be completed and fleshed out. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52322 Regards, Graham --
Re: [RE-VOTE] adoption of mod_firehose MODULE
On 3/1/2012 12:11 PM, William A. Rowe Jr. wrote: A proposal to adopt mod_firehose is attached. [ ] Option 1: adopt as trunk module [X] Option 2: adopt only as subproject [ ] Option 3: do not adopt
Re: Technical reasons for -1 votes (?)
On 2/29/2012 6:25 PM, Roy T. Fielding wrote: Yes, but they are modules. Hence, their mere existence in our tree is not a technical reason to exclude them. We have a modular architecture so that people who don't want a module don't have to build it. Which explains mod_macro how, exactly?
Re: [RE-VOTE] adoption of mod_firehose MODULE
On Mar 1, 2012, at 1:11 PM, William A. Rowe Jr. wrote: Let's simply reset this whole mess. A proposal to adopt mod_firehose is attached. [X] Option 1: adopt as trunk module [ ] Option 2: adopt only as subproject [ ] Option 3: do not adopt
Re: [RE-VOTE] adoption of mod_firehose MODULE
On Mar 1, 2012, at 10:11 AM, William A. Rowe Jr. wrote: Let's simply reset this whole mess. A proposal to adopt mod_firehose is attached. [X] Option 1: adopt as trunk module [ ] Option 2: adopt only as subproject [ ] Option 3: do not adopt Dimpled chad: I would support option 2 if 1 doesn't have traction. S. -- scte...@apache.orghttp://www.temme.net/sander/ PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A View my availability: http://tungle.me/sctemme
Re: [RE-VOTE] adoption of mod_firehose MODULE
On 3/1/2012 12:40 PM, Sander Temme wrote: Dimpled chad: I would support option 2 if 1 doesn't have traction. Yup - that's implicit.
Re: [RE-VOTE] adoption of mod_firehose MODULE
On Mar 1, 2012 1:29 PM, Jim Jagielski j...@jagunet.com wrote: On Mar 1, 2012, at 1:11 PM, William A. Rowe Jr. wrote: Let's simply reset this whole mess. A proposal to adopt mod_firehose is attached. [X] Option 1: adopt as trunk module [ ] Option 2: adopt only as subproject [ ] Option 3: do not adopt +1 for Option 1.
Re: Technical reasons for -1 votes (?)
On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote: On 2/29/2012 6:25 PM, Roy T. Fielding wrote: Yes, but they are modules. Hence, their mere existence in our tree is not a technical reason to exclude them. We have a modular architecture so that people who don't want a module don't have to build it. Which explains mod_macro how, exactly? At this point, my head exploded Scanners-like...
Re: setting up testing
On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt mamf...@gmail.com wrote: Want to get started on this. I read the links from http://httpd.apache.org/test/ and think I understand the flood subproject. From reading the forums here recently I get the impression that more than flood is being used, or even something other than flood. Looking for assistance and suggestions. perl framework... get svn on your AIX box if you don't have it already check out /httpd/test/framework/trunk/ perl Makefile.PL -apxs /path/to/apxs t/TEST t/TEST -clean No it won't be fun because things will fail and there will be many different reasons, few if any obvious ones :) You will likely need to install more Perl modules... Some old instructions of mine: perl -MCPAN -e 'shell' cpaninstall Test::Harness cpaninstall URI cpaninstall LWP::Protocol::https cpaninstall HTTP::DAV cpaninstall Bundle::ApacheTest cpaninstall LWP::Simple (dunno if this is current or everything you need on your level of AIX; this was for OpenSolaris a couple of years ago)
thread ID
Hello, I would need a memory buffer associated per worker thread (in the worker MPM) or to each process (in the prefork MPM). In order to do that, I would need a map thread-buffer. So, I would need a sort of thread ID/key/handle that stays the same during the lifetime of the thread and no two threads in the same process can have the same ID/key/handle. What is the most portable way to get this thread ID? I thought of r-connection-id. It works but it is not very portable as it is not guaranteed that two connections created by the same thread will have the same id. They do for now. If r-connection-sbh was not opaque it would be great, because sbh-thread_num would be exactly what I need. I could also use pthread_self. It works too but, in general, it is not guaranteed that the worker threads are pthreads. Thank you for your help. Sorin _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you.
Re: [RE-VOTE] adoption of mod_firehose MODULE
Seems dangerous to even comment in this flow - but as I am all about thinking testing at the moment - is there any thought about how to test this. From a packaging point of view I would expect tooling to be able to test are included functions. As a user I would expect anything in trunk (what I would call main) to be guaranteed. I cannot have an opinion about the reasoning for placing something in, or not in trunk, and I would expect something to at least have gone through some sort of testing process - live testing - before committing anything to a product/service. Before testing was completed I would only dare speaking of an intention to add. Isnt it something along the lines of: The proof of the pudding is the eating. To me this is just mod_foo, and as far as I know it has never been tested. (If it is already in trunk maybe I have already compiled it and just do not know it :p) - and that alone would make me postpone a non-reversible decision. Makes me think of what someone old and wise said to me when I was young: you (or she) only has to say Yes, or even (yes) once. On Thu, Mar 1, 2012 at 8:33 PM, Greg Stein gst...@gmail.com wrote: On Mar 1, 2012 1:29 PM, Jim Jagielski j...@jagunet.com wrote: On Mar 1, 2012, at 1:11 PM, William A. Rowe Jr. wrote: Let's simply reset this whole mess. A proposal to adopt mod_firehose is attached. [X] Option 1: adopt as trunk module [ ] Option 2: adopt only as subproject [ ] Option 3: do not adopt +1 for Option 1.
Re: setting up testing
perl with -MCPAN I used to use a lot, getting svn - personal build via a personal build is a different story. Guess I'll have to hunt down a package of RPM's for now and solve the core dump problem (in sqlite3 I have found at least). Macros are nice for coding, but less nice when working through dbx (although I used to be an expert with both adb and debug.com) Sigh... Thanks Jeff! On Thu, Mar 1, 2012 at 9:01 PM, Jeff Trawick traw...@gmail.com wrote: On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt mamf...@gmail.com wrote: Want to get started on this. I read the links from http://httpd.apache.org/test/ and think I understand the flood subproject. From reading the forums here recently I get the impression that more than flood is being used, or even something other than flood. Looking for assistance and suggestions. perl framework... get svn on your AIX box if you don't have it already check out /httpd/test/framework/trunk/ perl Makefile.PL -apxs /path/to/apxs t/TEST t/TEST -clean No it won't be fun because things will fail and there will be many different reasons, few if any obvious ones :) You will likely need to install more Perl modules... Some old instructions of mine: perl -MCPAN -e 'shell' cpaninstall Test::Harness cpaninstall URI cpaninstall LWP::Protocol::https cpaninstall HTTP::DAV cpaninstall Bundle::ApacheTest cpaninstall LWP::Simple (dunno if this is current or everything you need on your level of AIX; this was for OpenSolaris a couple of years ago)
Re: setting up testing
One quick question: can I assume that the test is ideally in a different machine than the httpd system being tested, or do the tests assume localhost? On Thu, Mar 1, 2012 at 8:50 PM, Michael Felt mamf...@gmail.com wrote: Want to get started on this. I read the links from http://httpd.apache.org/test/ and think I understand the flood subproject. From reading the forums here recently I get the impression that more than flood is being used, or even something other than flood. Looking for assistance and suggestions. Michael
Re: setting up testing
On Thu, Mar 1, 2012 at 3:17 PM, Michael Felt mamf...@gmail.com wrote: One quick question: can I assume that the test is ideally in a different machine than the httpd system being tested, or do the tests assume localhost? To be honest I haven't looked, but I suspect it is local host only... Once you have the test suite installed somewhere, try t/TEST -help and you'll see a multitude of options, some of which are for controlling the test environment more closely than with the very basic instructions I gave. Come to think of it, try it first on Linux and get it running cleanly there with help of dev@ as necessary, then when on AIX and possibly stumbling through issues getting the right CPAN packages installed you'll already know what it is supposed to look like. And of course you can play with the available test variations. On Thu, Mar 1, 2012 at 8:50 PM, Michael Felt mamf...@gmail.com wrote: Want to get started on this. I read the links from http://httpd.apache.org/test/ and think I understand the flood subproject. From reading the forums here recently I get the impression that more than flood is being used, or even something other than flood. Looking for assistance and suggestions. Michael -- Born in Roswell... married an alien...
Re: TESTING of mod_firehose MODULE
On 3/1/2012 2:05 PM, Michael Felt wrote: Seems dangerous to even comment in this flow - but as I am all about thinking testing at the moment - is there any thought about how to test this. From a packaging point of view I would expect tooling to be able to test are included functions. As a user I would expect anything in trunk (what I would call main) to be guaranteed. Changing the subject (please do this yourself next time)... 1. it is in trunk; if you've checked out trunk you likely compiled it and have bin/firehose and modules/mod_firehose.so - and can review the doc page. 2. if it weren't in trunk, the proposer included links to the module. Just drop it in and review it. 3. it's open source. The httpd legacy releases, current stable release and trunk development branch come with exactly one guarantee - if it's broke, you have all the pieces. Maybe I'm not understanding your question?
Re: setting up testing
On 3/1/2012 2:17 PM, Michael Felt wrote: One quick question: can I assume that the test is ideally in a different machine than the httpd system being tested, or do the tests assume localhost? You can do either, see t/TEST --help
Re: Technical reasons for -1 votes (?)
On 3/1/2012 1:58 PM, Jim Jagielski wrote: On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote: On 2/29/2012 6:25 PM, Roy T. Fielding wrote: Yes, but they are modules. Hence, their mere existence in our tree is not a technical reason to exclude them. We have a modular architecture so that people who don't want a module don't have to build it. Which explains mod_macro how, exactly? At this point, my head exploded Scanners-like... Funny, mine had exploded at the dis-congruity of; mod_ftp is there because it isn't an HTTP server. which is apropos of what? This isn't an ajp or scgi or fastcgi server either, it's an http server, which means we should pull out those interfaces?
Re: setting up testing
On Thu, Mar 1, 2012 at 3:14 PM, Michael Felt mamf...@gmail.com wrote: perl with -MCPAN I used to use a lot, getting svn - personal build via a personal build is a different story. Guess I'll have to hunt down a package of RPM's for now and solve the core dump problem (in sqlite3 I have found at least). Macros are nice for coding, but less nice when working through dbx (although I used to be an expert with both adb and debug.com) I think I've suggested this before, but the path of least resistance on AIX is the java-based svnkit for svn.
Re: setting up testing
yes you have, and I lost the info ... will start the search now... first on linux: assumes you have a linux box ready and waiting, which i dont. However, in 20 minutes I can have a new clean AIX sandbox - so I'll suffer through a bit. CPAN works very well is my memory of it. On Thu, Mar 1, 2012 at 9:45 PM, Eric Covener cove...@gmail.com wrote: On Thu, Mar 1, 2012 at 3:14 PM, Michael Felt mamf...@gmail.com wrote: perl with -MCPAN I used to use a lot, getting svn - personal build via a personal build is a different story. Guess I'll have to hunt down a package of RPM's for now and solve the core dump problem (in sqlite3 I have found at least). Macros are nice for coding, but less nice when working through dbx (although I used to be an expert with both adb and debug.com) I think I've suggested this before, but the path of least resistance on AIX is the java-based svnkit for svn.
Re: [RE-VOTE] adoption of mod_firehose MODULE
Modules do not have to be tested *before* they appear in trunk. That's putting the cart before the horse. Part of the development process (while in trunk) is doing the testing portion. And hey... if it never gets tested, then it gets marked as experimental and we all move on. Cheers, -g On Thu, Mar 1, 2012 at 15:05, Michael Felt mamf...@gmail.com wrote: Seems dangerous to even comment in this flow - but as I am all about thinking testing at the moment - is there any thought about how to test this. From a packaging point of view I would expect tooling to be able to test are included functions. As a user I would expect anything in trunk (what I would call main) to be guaranteed. I cannot have an opinion about the reasoning for placing something in, or not in trunk, and I would expect something to at least have gone through some sort of testing process - live testing - before committing anything to a product/service. Before testing was completed I would only dare speaking of an intention to add. Isnt it something along the lines of: The proof of the pudding is the eating. To me this is just mod_foo, and as far as I know it has never been tested. (If it is already in trunk maybe I have already compiled it and just do not know it :p) - and that alone would make me postpone a non-reversible decision. Makes me think of what someone old and wise said to me when I was young: you (or she) only has to say Yes, or even (yes) once. On Thu, Mar 1, 2012 at 8:33 PM, Greg Stein gst...@gmail.com wrote: On Mar 1, 2012 1:29 PM, Jim Jagielski j...@jagunet.com wrote: On Mar 1, 2012, at 1:11 PM, William A. Rowe Jr. wrote: Let's simply reset this whole mess. A proposal to adopt mod_firehose is attached. [X] Option 1: adopt as trunk module [ ] Option 2: adopt only as subproject [ ] Option 3: do not adopt +1 for Option 1.
Re: [RE-VOTE] adoption of mod_firehose MODULE
On 3/1/2012 3:02 PM, Greg Stein wrote: Modules do not have to be tested *before* they appear in trunk. That's putting the cart before the horse. Part of the development process (while in trunk) is doing the testing portion. And hey... if it never gets tested, then it gets marked as experimental and we all move on. In fact there is an modules/experimental/ tree; mod_noloris is currently one such module. Of course, if it never gets tested is a handwave. There's obviously no way for the pmc to assert committers have tested it. The only filter is the acceptance vote. This submitted module was not committed to modules/experimental/, but rather in modules/debugging/ If your desire was to mark this module experimental, you may want to refine your vote to be more explicit. As a diagnostic tool this module is toxic in resource consumption, so in theory, any bugs in this tool are unlikely to cause more pain than using the tool in the first place.
Re: [RE-VOTE] adoption of mod_firehose MODULE
On Mar 1, 2012, at 4:02 PM, Greg Stein wrote: Modules do not have to be tested *before* they appear in trunk. That's putting the cart before the horse. Part of the development process (while in trunk) is doing the testing portion. And hey... if it never gets tested, then it gets marked as experimental and we all move on. This is why I'm not understanding why this particular module (or set of modules) is getting this level of debate and scrutiny. We're talking about adding them to trunk, not in a release. Presumably we wouldn't put them in a release if there was a problem with them. I've often thought that modules like, say, mod_ftp, would have a much greater chance of being successful if they were in trunk rather than it being several additional steps to obtain. I'm +1 to having this in trunk, but am voting based on the community aspects, rather than the technical ones. I figure the technical aspects will work themselves out in trunk ... or they won't, and we'll drop it from a release branch. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Win VC10 project files convert
On 2/26/2012 10:11 AM, Steffen wrote: When I recall on the list is stated that .dsw and .dsp files cannot directly be used by VC10, so we should drop them. Correct me if I have read/understood wrong. I will not state that the Express version doesn't, because by the time it came out, I had been used to the dual conversion process because the Pro beta did not. However, I can also recall a mail to dev that said same, and I believe this person was using the Express version. But in the MS docu I read: By using Visual C++ 2010, you can open and save a project that was built in Visual C++ version 6 or later. Visual C++ will convert the project automatically. The upgrade process creates project files that have the extension .vcxproj, and does not remove old project files (.dsp, .vcproj). Tried as test with APR, and yes double clicking the dsp, it converts and builds fine. Later I try HTTPD. I have the Pro version now and tried httpd package last night and the outcome was less than I'd hoped, it just did not do it correctly IMO. Which led to nothing being able to find libs to link to. I just now grabbed the vcproj files from my VC9 build and converted them, no problems so far. One thing I am now noticing is that project dependencies that were set in VC9 cannot be removed in VC10. Gregg
Re: Technical reasons for -1 votes (?)
On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote: On 2/29/2012 6:25 PM, Roy T. Fielding wrote: On Feb 29, 2012, at 9:42 AM, William A. Rowe Jr. wrote: Let's take Roy's position on the attached vote discussion, it's relevant. These new modules are certainly additions/deletions to httpd. Yes, but they are modules. Hence, their mere existence in our tree is not a technical reason to exclude them. We have a modular architecture so that people who don't want a module don't have to build it. In fact, it was exactly this type of argument in 1995 that caused rst to focus on creating a modular architecture. Ok, so to clarify, you are reversing your answer to Joe? The LDAP changes were a change to a module. Not an httpd-wide API, just a module. So you are saying that your comment to Joe, The API was moved to *this* project and all of the names were changed. It is, effectively, a new public API for this project. was a misinformed statement (as it moved the ldap code into mod_ldap and not into the core API). That veto was unjustified? Or rather, had we not exported a single symbol, then the veto was unjustified? I don't remember the details, but it was presented by you as a new API. It was described by you as the addition of new LDAP libraries to httpd. And it was most certainly a change to the existing code in mod_ldap. Had it been presented as a new module with a new name and optional configuration, I would have said new modules only need one committer to maintain and a majority vote to decide if there is any objections. Quite frankly, I don't care either way for either change. What I care about is continual use of procedural bullshit to justify interference with other people scratching their own itches. If you don't like the module, then don't use it. If it has security holes or licensing issues, then those are grounds for a veto. If you don't like Grahams's attitude, that's too frigging bad -- find another way to vent your frustration or try to resolve it via the PMC, but don't mix it with a technical vote. If there were dependencies or license conditions brought in that somehow harmed the server without the module being active, then that would be a technical objection. There was no such case for the ldap change, so you are saying that specific veto was unjustified, right? Anyways, all of this is distraction, let's drill in further to your analysis; Traditionally, we have allowed any module that has at least one willing volunteer committer to maintain it. And I agree with Jim, none of the subprojects have been as successful as just placing the code in the main tree. Allowed it by... voting to accept it, right? I accept that all of my colleagues have different rationals for their +/- votes. Right now, just about 3% of the committee are willing to entertain these module additions to httpd trunk and 1.5% are against adding these to trunk. I chalk this up to burnout, 2.4 was very complex to release and people know their +1 votes are commitments and alter the httpd tarball for better or worse. If a vote is required (i.e., anyone objects), then it is a majority vote with minimal quorum (three +1s), as usual. If there was a vote to add this module to core, that would be lovely, we could vote on it. Sadly, minfrin offered no such vote, and whatever your conclusion on the 'better course' - it was not voted on, and you hadn't expressed a vote to adopt it in either case. I submit that there was confusion and the right thing to do would be to ask politely for the confusion to be resolved by an actual vote. It would help if you were not being an ass about it and randomly accusing people of nefarious behavior just because they don't give a damn about this particular difference of opinion. And it isn't Graham's responsibility to run the vote. I have no idea why mod_fcgi is in a subproject. mod_ftp is there because it isn't an HTTP server. mod_aspdotnet had all sorts of licensing issues that I never quite figured out. Nonsequitor, if we want to launch into a discussion of subprojects vs. modules, that's great. That wasn't the conversation minfrin started, and that's why I have a VETO on the commit. Correct the mis-execution by conforming to the vote he held, or correct the vote instead. I've VETOED a commit which is something other than what was voted on because the project did not consent to his action. You are confused. You don't need to veto a non-event -- just conduct the vote properly and be done. If there are two other committers who will vote with Jim for this project to accept one or more of these modules into trunk (rather than subproject), and someone will finish the ip-clearance, I'm great with that. If none of that happens I will revert this mess. Fine with me, if you stop blathering about it and conduct the vote properly. You know how to conduct a vote. I see no reason not to commit mod_firehose, though I
Re: Technical reasons for -1 votes (?)
On Mar 1, 2012, at 12:28 PM, William A. Rowe Jr. wrote: On 3/1/2012 1:58 PM, Jim Jagielski wrote: On Mar 1, 2012, at 1:25 PM, William A. Rowe Jr. wrote: On 2/29/2012 6:25 PM, Roy T. Fielding wrote: Yes, but they are modules. Hence, their mere existence in our tree is not a technical reason to exclude them. We have a modular architecture so that people who don't want a module don't have to build it. Which explains mod_macro how, exactly? At this point, my head exploded Scanners-like... Funny, mine had exploded at the dis-congruity of; mod_ftp is there because it isn't an HTTP server. which is apropos of what? It is a different product. If it were changed so that it could be meaningfully documented as part of the HTTP server, then I'd suggest it be moved to trunk too. This isn't an ajp or scgi or fastcgi server either, it's an http server, which means we should pull out those interfaces? Those are all gateway interfaces *used* by an HTTP server to communicate with a backend. If we had a better way to ship modular code, like CPAN or gem, they wouldn't be part of our core product. But we don't, so they are (or should be). Roy
Re: [RE-VOTE] adoption of mod_firehose MODULE
On Thu, Mar 1, 2012 at 16:30, Rich Bowen rbo...@rcbowen.com wrote: ... I've often thought that modules like, say, mod_ftp, would have a much greater chance of being successful if they were in trunk rather than it being several additional steps to obtain. I'm +1 to having this in trunk, but am voting based on the community aspects, rather than the technical ones. I figure the technical aspects will work themselves out in trunk ... or they won't, and we'll drop it from a release branch. Exactly. In the subversion project, we always strive to do development directly on trunk (rather than branches). Keeping stuff in trunk gives it many more eyeballs and testing. New features might be buggy on trunk, but just don't use it yet is a good response :-) Cheers, -g
Re: [RE-VOTE] adoption of mod_firehose MODULE
I learned something tonight :) On Thu, Mar 1, 2012 at 11:37 PM, Greg Stein gst...@gmail.com wrote: On Thu, Mar 1, 2012 at 16:30, Rich Bowen rbo...@rcbowen.com wrote: ... I've often thought that modules like, say, mod_ftp, would have a much greater chance of being successful if they were in trunk rather than it being several additional steps to obtain. I'm +1 to having this in trunk, but am voting based on the community aspects, rather than the technical ones. I figure the technical aspects will work themselves out in trunk ... or they won't, and we'll drop it from a release branch. Exactly. In the subversion project, we always strive to do development directly on trunk (rather than branches). Keeping stuff in trunk gives it many more eyeballs and testing. New features might be buggy on trunk, but just don't use it yet is a good response :-) Cheers, -g
Re: setting up testing
trying: # svnkit-1.3.7/bin/jsvn checkout http://svn.apache.org/viewvc/httpd/test/framework/trunk test get: svn: Repository moved permanently to '/viewvc/httpd/test/framework/trunk'; please relocate svn: OPTIONS request failed on '/viewvc/httpd/test/framework/trunk' Explanation please. On Thu, Mar 1, 2012 at 9:01 PM, Jeff Trawick traw...@gmail.com wrote: On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt mamf...@gmail.com wrote: Want to get started on this. I read the links from http://httpd.apache.org/test/ and think I understand the flood subproject. From reading the forums here recently I get the impression that more than flood is being used, or even something other than flood. Looking for assistance and suggestions. perl framework... get svn on your AIX box if you don't have it already check out /httpd/test/framework/trunk/ perl Makefile.PL -apxs /path/to/apxs t/TEST t/TEST -clean No it won't be fun because things will fail and there will be many different reasons, few if any obvious ones :) You will likely need to install more Perl modules... Some old instructions of mine: perl -MCPAN -e 'shell' cpaninstall Test::Harness cpaninstall URI cpaninstall LWP::Protocol::https cpaninstall HTTP::DAV cpaninstall Bundle::ApacheTest cpaninstall LWP::Simple (dunno if this is current or everything you need on your level of AIX; this was for OpenSolaris a couple of years ago)
Re: setting up testing
On Thu, Mar 1, 2012 at 8:09 PM, Michael Felt mamf...@gmail.com wrote: trying: # svnkit-1.3.7/bin/jsvn checkout http://svn.apache.org/viewvc/httpd/test/framework/trunk test get: svn: Repository moved permanently to '/viewvc/httpd/test/framework/trunk'; please relocate svn: OPTIONS request failed on '/viewvc/httpd/test/framework/trunk' Explanation please. viewvc is a CGI script, not part of the svn path This page here has an example of checking out something under the httpd project: http://httpd.apache.org/dev/devnotes.html On Thu, Mar 1, 2012 at 9:01 PM, Jeff Trawick traw...@gmail.com wrote: On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt mamf...@gmail.com wrote: Want to get started on this. I read the links from http://httpd.apache.org/test/ and think I understand the flood subproject. From reading the forums here recently I get the impression that more than flood is being used, or even something other than flood. Looking for assistance and suggestions. perl framework... get svn on your AIX box if you don't have it already check out /httpd/test/framework/trunk/ perl Makefile.PL -apxs /path/to/apxs t/TEST t/TEST -clean No it won't be fun because things will fail and there will be many different reasons, few if any obvious ones :) You will likely need to install more Perl modules... Some old instructions of mine: perl -MCPAN -e 'shell' cpaninstall Test::Harness cpaninstall URI cpaninstall LWP::Protocol::https cpaninstall HTTP::DAV cpaninstall Bundle::ApacheTest cpaninstall LWP::Simple (dunno if this is current or everything you need on your level of AIX; this was for OpenSolaris a couple of years ago) -- Born in Roswell... married an alien...
IP Clearance? NAK
On 3/1/2012 4:17 PM, Roy T. Fielding wrote: On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote: Perhaps you are signing up to do that ip-clearance, since it doesn't seem to be coming from the committer. IP clearance for an existing committer is BULLSHIT. I already cleared that with Legal when I was chair of this project. Somehow, having chaired the HTTP Server project for 2 years, I had missed the memo. This information is not being communicated. Thank you for enlightening me, our chair Eric, and the rest of the TLP communities. The HTTP Server Project will proceed to ignore the IP Clearance process laid out by the Incubator for all incoming contributions from any actual project committer or their employer, until informed otherwise by the President of the foundation.
Re: IP Clearance? NAK
On Thu, Mar 1, 2012 at 20:52, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 3/1/2012 4:17 PM, Roy T. Fielding wrote: On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote: Perhaps you are signing up to do that ip-clearance, since it doesn't seem to be coming from the committer. IP clearance for an existing committer is BULLSHIT. I already cleared that with Legal when I was chair of this project. Somehow, having chaired the HTTP Server project for 2 years, I had missed the memo. This information is not being communicated. Thank you for enlightening me, our chair Eric, and the rest of the TLP communities. The HTTP Server Project will proceed to ignore the IP Clearance process laid out by the Incubator for all incoming contributions from any actual project committer or their employer, until informed otherwise by the President of the foundation. Why don't you stop with your passive-aggressive bullshit, and read the thread over on legal-discuss where we talked about fixing the short form IP Clearance process. The IP policies have not changed, but they *should*, along the lines Roy suggests in that thread. The HTTP PMC cannot ignore the clearance process. But we do need to fix the process. And we don't need your crap. -g
Re: IP Clearance? NAK
On 3/1/2012 9:08 PM, Greg Stein wrote: Why don't you stop with your passive-aggressive bullshit, and read the thread over on legal-discuss where we talked about fixing the short form IP Clearance process. The IP policies have not changed, but they *should*, along the lines Roy suggests in that thread. Greg; Roy just stated, it's not applicable and invalid. Ergo the project will ignore this process until either 1. the Legal Committee or 2. the ASF President inform the HTTP project of specific external steps that it must follow with respect to IP intake offered by committers (and as proxy for their employers). Incubator isn't actually given any jurisdiction over projects. Legal committee is... and Roy states that Legal cleared HTTP from following this (quoting) BULLSHIT process in respect to committer contributions. I am getting incredibly frustrated with the fact that three founders and current board members have no common institutional memory. You three probably should just hang up the hats already if you can't agree for even a single day on a recollection any particular precedent. I might be passive aggressive some days, but I'm not a psychopathic schizophrenic as the three headed RoyGregJim beast is. In the meantime, there is a project to run. Roy acting as a former officer has informed Eric, the current chair, and myself, a former chair, of specific internal and official communication with the legal committee that this process is not applicable to contributions from committers, and we will respect Roy's recollection as former Chair until we hear otherwise from an officer (not a schizo Director) of the foundation.
Re: Technical reasons for -1 votes (?)
On 3/1/2012 4:17 PM, Roy T. Fielding wrote: On Mar 1, 2012, at 9:20 AM, William A. Rowe Jr. wrote: Or rather, had we not exported a single symbol, then the veto was unjustified? I don't remember the details, but it was presented by you as a new API. It was described by you as the addition of new LDAP libraries to httpd. And it was most certainly a change to the existing code in mod_ldap. Roy, I'm sorry. Obviously I miscommunicated. It was a former API. The proposal was to fold that behavior into a single self-contained module. I will present this in the coming month in a manner that conforms to your understanding of a module vs. an API, such that no individual can veto it, and the dozen+ of us can vote for it and be forever rid of the garbage former-API constraint, ignoring those crazy voices from the wilderness. If a vote is required (i.e., anyone objects), then it is a majority vote with minimal quorum (three +1s), as usual. That's the page I started on, thanks for confirming! These modules did NOT have majorities for inclusion in trunk. Tonight, one finally does. I never believed I had a veto, only 1 vote against blind implied consent. I submit that there was confusion and the right thing to do would be to ask politely for the confusion to be resolved by an actual vote. It would help if you were not being an ass about it and randomly accusing people of nefarious behavior just because they don't give a damn about this particular difference of opinion. And it isn't Graham's responsibility to run the vote. Ah, but you see, that's the rub. There WAS a vote. A proposal was made by Graham, a vote was held by Graham, and a DIFFERENT course of action was followed by Graham. Amazingly, Graham ran the successful vote, for an altogether different outcome. That is what is objectionable; if there is anything in the past months demonstrates psychotic behavior, it is not my objections to what had transpired, but what actually transpired. Quoting the private list, where there is to be no development discussion (so ergo these comments cannot be confidential); On 12/8/2011 7:40 AM, Graham Leggett wrote: On 08 Dec 2011, at 3:30 PM, William A. Rowe Jr. wrote: But I think we are saying the same thing... I just wanted to be sure this was understood as [poll] Potential Adoption of... and not something actually adopted as in your message subject. The word proposal means exactly that, and I haven't seen any misunderstanding so far from anybody. at which point, the entire discussion went sideways once Graham adopted the input of private@ development discussion into his next actions. As the Chief Agent and Advocate against dev discussions happening in private off of the dev list, I'm relying on you personally to ensure this doesn't reoccur.
Re: setting up testing
In other words, I needed to look lower at: so I should be using: svn checkout https://svn.apache.org/repos/asf/perl/Apache-Test/trunk Apache-Test Thanks On Fri, Mar 2, 2012 at 2:29 AM, Jeff Trawick traw...@gmail.com wrote: On Thu, Mar 1, 2012 at 8:09 PM, Michael Felt mamf...@gmail.com wrote: trying: # svnkit-1.3.7/bin/jsvn checkout http://svn.apache.org/viewvc/httpd/test/framework/trunk test get: svn: Repository moved permanently to '/viewvc/httpd/test/framework/trunk'; please relocate svn: OPTIONS request failed on '/viewvc/httpd/test/framework/trunk' Explanation please. viewvc is a CGI script, not part of the svn path This page here has an example of checking out something under the httpd project: http://httpd.apache.org/dev/devnotes.html On Thu, Mar 1, 2012 at 9:01 PM, Jeff Trawick traw...@gmail.com wrote: On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt mamf...@gmail.com wrote: Want to get started on this. I read the links from http://httpd.apache.org/test/ and think I understand the flood subproject. From reading the forums here recently I get the impression that more than flood is being used, or even something other than flood. Looking for assistance and suggestions. perl framework... get svn on your AIX box if you don't have it already check out /httpd/test/framework/trunk/ perl Makefile.PL -apxs /path/to/apxs t/TEST t/TEST -clean No it won't be fun because things will fail and there will be many different reasons, few if any obvious ones :) You will likely need to install more Perl modules... Some old instructions of mine: perl -MCPAN -e 'shell' cpaninstall Test::Harness cpaninstall URI cpaninstall LWP::Protocol::https cpaninstall HTTP::DAV cpaninstall Bundle::ApacheTest cpaninstall LWP::Simple (dunno if this is current or everything you need on your level of AIX; this was for OpenSolaris a couple of years ago) -- Born in Roswell... married an alien...
Re: setting up testing
Seems to have worked, and only a minor error/warning (I hope) - twice... Manifying blib/man3/Apache::TestHandler.3 lib/Apache/TestHandler.pm:106: Unknown command paragraph =encoding utf8 So, I expect I'll still have to load more stuff from CPAN, once I find the start button... On Fri, Mar 2, 2012 at 8:34 AM, Michael Felt mamf...@gmail.com wrote: In other words, I needed to look lower at: so I should be using: svn checkout https://svn.apache.org/repos/asf/perl/Apache-Test/trunk Apache-Test Thanks On Fri, Mar 2, 2012 at 2:29 AM, Jeff Trawick traw...@gmail.com wrote: On Thu, Mar 1, 2012 at 8:09 PM, Michael Felt mamf...@gmail.com wrote: trying: # svnkit-1.3.7/bin/jsvn checkout http://svn.apache.org/viewvc/httpd/test/framework/trunk test get: svn: Repository moved permanently to '/viewvc/httpd/test/framework/trunk'; please relocate svn: OPTIONS request failed on '/viewvc/httpd/test/framework/trunk' Explanation please. viewvc is a CGI script, not part of the svn path This page here has an example of checking out something under the httpd project: http://httpd.apache.org/dev/devnotes.html On Thu, Mar 1, 2012 at 9:01 PM, Jeff Trawick traw...@gmail.com wrote: On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt mamf...@gmail.com wrote: Want to get started on this. I read the links from http://httpd.apache.org/test/ and think I understand the flood subproject. From reading the forums here recently I get the impression that more than flood is being used, or even something other than flood. Looking for assistance and suggestions. perl framework... get svn on your AIX box if you don't have it already check out /httpd/test/framework/trunk/ perl Makefile.PL -apxs /path/to/apxs t/TEST t/TEST -clean No it won't be fun because things will fail and there will be many different reasons, few if any obvious ones :) You will likely need to install more Perl modules... Some old instructions of mine: perl -MCPAN -e 'shell' cpaninstall Test::Harness cpaninstall URI cpaninstall LWP::Protocol::https cpaninstall HTTP::DAV cpaninstall Bundle::ApacheTest cpaninstall LWP::Simple (dunno if this is current or everything you need on your level of AIX; this was for OpenSolaris a couple of years ago) -- Born in Roswell... married an alien...
Re: setting up testing
I have seen the name apxs many times in the past, t/TEST -help names an -apxs location of apxs (default is from Apache2::BuildConfig) Currently I have a partition (actually a WPAR) that only has perl updated via cpan and Apache-Test loaded. Since I wont be starting the httpd locally, do I still need apxs? It looks like it is used for start/stop/reconfig? Off to work, thanks again for the help! On Fri, Mar 2, 2012 at 8:42 AM, Michael Felt mamf...@gmail.com wrote: Seems to have worked, and only a minor error/warning (I hope) - twice... Manifying blib/man3/Apache::TestHandler.3 lib/Apache/TestHandler.pm:106: Unknown command paragraph =encoding utf8 So, I expect I'll still have to load more stuff from CPAN, once I find the start button... On Fri, Mar 2, 2012 at 8:34 AM, Michael Felt mamf...@gmail.com wrote: In other words, I needed to look lower at: so I should be using: svn checkout https://svn.apache.org/repos/asf/perl/Apache-Test/trunk Apache-Test Thanks On Fri, Mar 2, 2012 at 2:29 AM, Jeff Trawick traw...@gmail.com wrote: On Thu, Mar 1, 2012 at 8:09 PM, Michael Felt mamf...@gmail.com wrote: trying: # svnkit-1.3.7/bin/jsvn checkout http://svn.apache.org/viewvc/httpd/test/framework/trunk test get: svn: Repository moved permanently to '/viewvc/httpd/test/framework/trunk'; please relocate svn: OPTIONS request failed on '/viewvc/httpd/test/framework/trunk' Explanation please. viewvc is a CGI script, not part of the svn path This page here has an example of checking out something under the httpd project: http://httpd.apache.org/dev/devnotes.html On Thu, Mar 1, 2012 at 9:01 PM, Jeff Trawick traw...@gmail.com wrote: On Thu, Mar 1, 2012 at 2:50 PM, Michael Felt mamf...@gmail.com wrote: Want to get started on this. I read the links from http://httpd.apache.org/test/ and think I understand the flood subproject. From reading the forums here recently I get the impression that more than flood is being used, or even something other than flood. Looking for assistance and suggestions. perl framework... get svn on your AIX box if you don't have it already check out /httpd/test/framework/trunk/ perl Makefile.PL -apxs /path/to/apxs t/TEST t/TEST -clean No it won't be fun because things will fail and there will be many different reasons, few if any obvious ones :) You will likely need to install more Perl modules... Some old instructions of mine: perl -MCPAN -e 'shell' cpaninstall Test::Harness cpaninstall URI cpaninstall LWP::Protocol::https cpaninstall HTTP::DAV cpaninstall Bundle::ApacheTest cpaninstall LWP::Simple (dunno if this is current or everything you need on your level of AIX; this was for OpenSolaris a couple of years ago) -- Born in Roswell... married an alien...
