Re: Concerns about suggested version strategy
On Fri, Oct 18, 2002 at 10:22:55AM -0700, Justin Erenkrantz wrote: All even numbered releases will be considered stable revisions. What do we do for bumping of major numbers? Say we want Apache 3.0. How do we do the -development release for that? Linux has done the 1.99 series to do development for 2.0. (What is Perl doing for 6.0 development?) i think what is currently being discussed with regard to the next stable linux release shows how you handle the version-before-major-jump numbering. the development tree is 2.5 -- the next stable tree could be either 2.6 or 3.0, depending on how major the differences are relative to 2.4. jumping the major number of the development branch presumes you know beforehand what major changes are going to go into that development branch. what happens when someone commits a change to 2.x that people then decide warrants making the next stable release a 3.x? jim
Re: what replaced --activate-module?
On Tue, Apr 09, 2002 at 02:13:51PM -0500, Austin Gonyou wrote: so for say php 4.1.2, when I do --with-apache2(instead of apxs2) I shouldn't have to activate the module in apache2 ./configure anymore? Is that correct? except that right now, there is no --with-apache2 option for php. (there is only --with-apxs2. and php 4.1.2 is not compatible with the recent release -- some api changed since php 4.1.2 was released.) jim
Re: dist/httpd/apache_1.3.22.tar.gz is redirected to 1.3.23
On Tue, Jan 29, 2002 at 08:56:09PM -0500, Jim Jagielski wrote: Rodent of Unusual Size wrote: 1. Why is a request for 1.3.22 being redirected to 1.3.23? No idea. mod_speling? jim
Re: [PATCH] RE: make distclean doesn't
On Sun, Sep 02, 2001 at 01:25:07PM -0400, Cliff Woolley wrote: On Sun, 2 Sep 2001, William A. Rowe, Jr. wrote: Which means it has nothing to do with cleaning the tree to a distribution state (or state 'ready for distribution'.) See, I think that's the difference of interpretation here. *I* interpret distclean to mean not ready for distribution but back to essentially the way it was when I unpacked the distribution. The difference being that I'd be irritated as hell if I lost my configuration information which has no impact on the state of the build environment, as opposed to the Makefiles and so on which do affect the state. If I make distclean, it means I want to start over again with the first step out of the tarball, namely configure. It doesn't mean I want to lose the options I passed to configure. it may be worth following the gnu project's lead on these targets, since they use the same names. http://www.gnu.org/prep/standards_55.html#SEC55 (for them, distclean == what is in the tarball.) jim
Re: Ready to go?
On Thu, Feb 01, 2001 at 09:03:04AM +, Matt Sergeant wrote: Is the libapreq release ready to go now mod_perl 1.25 is out? i put an updated snapshot of libapreq from cvs at http://www.apache.org/~jimw/httpd-apreq-20010202.tar.gz. if i could get a few people to double-check that it compiles for them with 1.25 (particularly under win32), i'll go ahead and put out 0.32. jim
Re: PerlIO patch
this is very similar to something that was part of randy's
win32 patch that i was going to do some more digging on before
applying. i'll try testing with 5.6 later today. if someone could
give it a whirl with 5.005, that would be cool.
jim
On Mon, Jan 08, 2001 at 10:36:17PM -0800, Doug MacEachern wrote:
this patch is required to work with perl-current (5.7.1-dev), it should
work with other Perls, but i have not tested.
Index: Request/Request.xs
===
RCS file: /home/cvs/httpd-apreq/Request/Request.xs,v
retrieving revision 1.7
diff -u -r1.7 Request.xs
--- Request/Request.xs2001/01/09 04:21:08 1.7
+++ Request/Request.xs2001/01/09 06:27:54
@@ -18,6 +18,13 @@
#define PerlLIO_close(fd) close((fd))
#endif
+#ifdef PerlIO
+typedef PerlIO * InputStream;
+#else
+typedef FILE * InputStream;
+#define PerlIO_importFILE(fp,flags) fp
+#endif
+
static char *r_keys[] = { _r, r, NULL };
static SV *r_key_sv(SV *in)
@@ -199,12 +206,12 @@
PROTOTYPES: DISABLE
-FILE *
+InputStream
ApacheUpload_fh(upload)
Apache::Upload upload
CODE:
-if (!(RETVAL = ApacheUpload_fh(upload))) {
+if (!(RETVAL = PerlIO_importFILE(ApacheUpload_fh(upload),0))) {
XSRETURN_UNDEF;
}
Re: Blank cookies
seems reasonable enough to me. committed.
thanks.
jim
On Dec 28, David N. Welton wrote:
If I set a cookie like:
Cookie bop; foo=bar;doo=wah; shoo=be ;d=bee;dot=dow
The current code doesn't handle it. I know it may be incorrect
but... what's the saying... be liberal with what you accept and
conservative with what you output (bad paraphrasing).
Comments?
--- download/httpd-apreq/c/apache_cookie.c Sat Dec 23 02:24:20 2000
+++ workshop/mod_dtcl/apache_cookie.c Thu Dec 28 18:09:50 2000
@@ -169,6 +169,11 @@
else {
c-values = ap_make_array(r-pool, 4, sizeof(char *));
}
+
+ if (!*pair) {
+ ApacheCookieAdd(c, );
+ }
+
while (*pair (val = ap_getword(r-pool, pair, ''))) {
ap_unescape_url((char *)val);
ApacheCookieAdd(c, val);
Re: libapreq (preliminary comments on the multipart.c code)
On Dec 11, Joe Schaefer wrote: I just got an account with apache.org (user joes). Have you been able to get a CVS tree going for apreq at apache.org? close. i've got doug's cvs tree, now i just have to wait for brian to fix the permissions on a directory and then integrate the stuff we've been working on. there's also new apreq-dev and apreq-cvs mailing lists (@httpd.apache.org, ezmlm-managed like the mod_perl lists). i've cc'd this there so it appears in the ezmlm archives. I put together a preliminary list.c/list.h API for dealing with dynamically resizing buffers. It's tailor made for handling most of the cumbersome problems that we face with implementing multipart/form-data posts. I'd appreciate feedback on how to improve it (one thing I'm considering is a direct BUFF interface.) The files are located at cool. i haven't had a chance to dig in yet, but it sounds great at first glance. i wouldn't worry about a direct BUFF interface, since one of the ToDo items is to port to apache-2.0, and BUFF is gone in 2.0. :) it may be worth looking at the 'ring' code from apr-util at http://www.apache.org/websrc/viewcvs.cgi/apr-util/include/ap_ring.h. 2) There seems to be an accounting error at the end of multipart_buffer_read. On a terminal CRLF, it should reduce the return value by one more (--len): good catch. Also, one serious problem with your last patch: the arrows in your linked list point the wrong way :) I have a patch to fix this, but obviously I'd prefer it if we incorporated the list.[ch] code I wrote to specfically deal with these issues. d'oh! i made sure i had the arguments to memcpy() the right way 'round (they weren't initially), but i missed that. shows you how much testing i did to check it was correct versus uses less memory. :) jim
