On 1/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: rooneg
Date: Sat Jan 7 20:48:50 2006
New Revision: 366985
URL: http://svn.apache.org/viewcvs?rev=366985view=rev
Log:
In theory, we now correctly implement all of the FastCGI protocol, so
there's no reason that request ids
On 1/8/06, Jim Jagielski [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Author: rooneg
Date: Sat Jan 7 13:37:40 2006
New Revision: 366926
Weird... Just yesterday I did the below, which allows us to
keep using FCGI headers where natural yet also resolves the
struct stuff I
On 1/8/06, Jim Jagielski [EMAIL PROTECTED] wrote:
On Jan 8, 2006, at 1:46 PM, Garrett Rooney wrote:
On 1/8/06, Jim Jagielski [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Author: rooneg
Date: Sat Jan 7 13:37:40 2006
New Revision: 366926
Weird... Just yesterday I did
On 1/8/06, Jim Jagielski [EMAIL PROTECTED] wrote:
If it's OK, I'll merge the best aspects of both together and commit
that...
Basically, it would be abstracting out the mapping between the header
struct and the actual array used, to use the header when logical
but avoid the mess of loads of
On 1/7/06, Garrett Rooney [EMAIL PROTECTED] wrote:
On 1/5/06, Garrett Rooney [EMAIL PROTECTED] wrote:
On 1/5/06, Ian Holsman [EMAIL PROTECTED] wrote:
this allows you to pass a 'path' to the fast cgi process
to use:
ProxyPass /forum fcgi-tcp://127.0.0.1:8005/foruX
request
On 1/8/06, Garrett Rooney [EMAIL PROTECTED] wrote:
On 1/7/06, Garrett Rooney [EMAIL PROTECTED] wrote:
On 1/5/06, Garrett Rooney [EMAIL PROTECTED] wrote:
On 1/5/06, Ian Holsman [EMAIL PROTECTED] wrote:
this allows you to pass a 'path' to the fast cgi process
to use:
ProxyPass
On 1/5/06, Garrett Rooney [EMAIL PROTECTED] wrote:
On 1/5/06, Ian Holsman [EMAIL PROTECTED] wrote:
this allows you to pass a 'path' to the fast cgi process
to use:
ProxyPass /forum fcgi-tcp://127.0.0.1:8005/foruX
request
/forum/zx will have a path_info of /foruX/zx
posting
On 1/5/06, Ian Holsman [EMAIL PROTECTED] wrote:
this allows you to pass a 'path' to the fast cgi process
to use:
ProxyPass /forum fcgi-tcp://127.0.0.1:8005/foruX
request
/forum/zx will have a path_info of /foruX/zx
posting it as a patch, as the code is a bit fugly.
The question is, what
On 1/4/06, Jim Jagielski [EMAIL PROTECTED] wrote:
On Jan 4, 2006, at 4:32 AM, Ian Holsman wrote:
I'm not sure why we aren't just reading the plen at the same time
as the clen... but as is when the 2nd header is read, it is not in
sync (out by padding-len bytes)
this patch makes it
On 1/4/06, Jim Jagielski [EMAIL PROTECTED] wrote:
On Jan 4, 2006, at 10:38 AM, Garrett Rooney wrote:
See the list archives from last week for my
attempts if you want someplace to start.
You mean: Message-Id:
[EMAIL PROTECTED] ??
That exact message is the version we finally went
On 1/4/06, Jim Jagielski [EMAIL PROTECTED] wrote:
How are you testing? Let me see if I can recreate
your test env here (or Paul's) so I can dig deeper.
I tested those changes with a simple fastcgi app that just dumps 50 or
60 bytes of content, then I manually messed with the size of the
On 1/4/06, Jim Jagielski [EMAIL PROTECTED] wrote:
Garrett Rooney wrote:
On 1/4/06, Jim Jagielski [EMAIL PROTECTED] wrote:
How are you testing? Let me see if I can recreate
your test env here (or Paul's) so I can dig deeper.
I tested those changes with a simple fastcgi app
On 1/3/06, Jim Jagielski [EMAIL PROTECTED] wrote:
Garrett Rooney wrote:
On 1/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jim
Date: Mon Jan 2 08:52:58 2006
New Revision: 365376
URL: http://svn.apache.org/viewcvs?rev=3D365376view=3Drev
Log:
Avoid magic numbers
On 1/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jim
Date: Mon Jan 2 10:25:42 2006
New Revision: 365387
URL: http://svn.apache.org/viewcvs?rev=365387view=rev
Log:
Temporary hack to allow testing to continue. Interesting that
other FCGI modules (like mod_fcgid) don't bother to
On 1/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jim
Date: Mon Jan 2 08:52:58 2006
New Revision: 365376
URL: http://svn.apache.org/viewcvs?rev=365376view=rev
Log:
Avoid magic numbers. Since we are reading the header, let's
be explicit about it. Also removes the need to clean
On 12/31/05, Rian Hunter [EMAIL PROTECTED] wrote:
Also I want to fix the folder hierarchy and put all the src in one
folder and the Makefiles in others, so it isn't so UNIX-centric.
Most of the suff you mentioned seems fine (in concept anyway), but I
don't really see the point of this one.
On 12/29/05, Garrett Rooney [EMAIL PROTECTED] wrote:
Here's a very lightly tested patch to allow mod_proxy_fcgi to deal
with fastcgi records with content length greater than AP_IOBUFSIZE.
If someone could double check the math to make sure it's correct in
all cases I'd appreciate it, I tested
On 12/29/05, Colm MacCarthaigh [EMAIL PROTECTED] wrote:
[1] and [3] on their own are simply enough, [2] is the crazy part.
Does any of this make any sense?
I don't know enough about [2] to say if it's possible or not, but it
makes sense at first glance. I'm highly in favor of [3], since it
On 12/30/05, Garrett Rooney [EMAIL PROTECTED] wrote:
On 12/29/05, Garrett Rooney [EMAIL PROTECTED] wrote:
Here's a very lightly tested patch to allow mod_proxy_fcgi to deal
with fastcgi records with content length greater than AP_IOBUFSIZE.
If someone could double check the math to make
There's a small bug in the fastcgi header parsing code, the chars need
to be treated as unsigned in order for all the shifting to work
properly...
Log follows, patch attached.
-garrett
Fix the extraction of shorts from the header parsing code.
* modules/proxy/mod_proxy_fcgi.c
(dispatch):
On 12/29/05, Jim Jagielski [EMAIL PROTECTED] wrote:
Personally, I think it would be cool to fold the fcgi branch
into httpd-trunk. I have some cycles coming up and it would
be cool to get that puppy official for trunk and maybe
even 2.2
No objection to merging it eventually, but I'd really
On 12/29/05, Brian McCallister [EMAIL PROTECTED] wrote:
On Dec 29, 2005, at 2:08 PM, Paul Querna wrote:
As for backport it to 2.2 Right now, I believe this should be
one of the headliner features for a 2.4 release in 8-12 months.
I am not a fan of backportitist. I am not saying I
Here's a very lightly tested patch to allow mod_proxy_fcgi to deal
with fastcgi records with content length greater than AP_IOBUFSIZE.
If someone could double check the math to make sure it's correct in
all cases I'd appreciate it, I tested it by reducing the buffers to
very small sizes, and it
On 12/26/05, Paul Querna [EMAIL PROTECTED] wrote:
Garrett Rooney wrote:
And here we have today's mod_proxy_fcgi patch, support for sending the
FASTCGI_STDIN records (which contain the data from the body of the
request) to the fastcgi process. Again, basic testing with a Ruby
fastcgi
On 12/26/05, Justin Erenkrantz [EMAIL PROTECTED] wrote:
On Mon, Dec 26, 2005 at 11:28:45PM -0800, Paul Querna wrote:
1) 1024 is tiny. Prolly should try something much higher.
How about using AP_IOBUFSIZE instead? -- justin
Makes sense to me. The next patch switches to using that for the
This patch makes the code for talking to the back end fastcgi process
use apr_poll, interleaving reads and writes as they become ready.
Note that it doesn't actually switch to nonblocking reads/writes, but
that can be done in another pass. This also switches to AP_IOBUFSIZE
for the read/write
On 12/27/05, Garrett Rooney [EMAIL PROTECTED] wrote:
Comments, as always, are more than welcome.
As Paul pointed out on IRC, this patch fails to parse the HTTP headers
coming back from the back end fastcgi process. Here's an updated
version that fixes that. Log follows, patch attached
On 12/27/05, Garrett Rooney [EMAIL PROTECTED] wrote:
On 12/27/05, Garrett Rooney [EMAIL PROTECTED] wrote:
Comments, as always, are more than welcome.
As Paul pointed out on IRC, this patch fails to parse the HTTP headers
coming back from the back end fastcgi process. Here's an updated
On 12/26/05, Paul Querna [EMAIL PROTECTED] wrote:
Garrett Rooney wrote:
I wasy playing around with the FastCGI stuff tonight, and I
implemented the next step in the request process, sending the
environment over to the backend fcgi process. This also involved
refactoring some
And here we have today's mod_proxy_fcgi patch, support for sending the
FASTCGI_STDIN records (which contain the data from the body of the
request) to the fastcgi process. Again, basic testing with a Ruby
fastcgi program indicates that it's at least minimally functional
Log follows, patch
So I've been taking a look at the new work Paul's been doing on the
fcgi-proxy-dev branch, and it looks really cool, but I've got some
questions on its direction. What's there now is the beginnings of
functionality to let you use mod_proxy to send requests for particular
parts of the URL space to
I wasy playing around with the FastCGI stuff tonight, and I
implemented the next step in the request process, sending the
environment over to the backend fcgi process. This also involved
refactoring some of the existing code a bit, removing unused
variables, etc, but nothing too extraordinary.
On 12/23/05, Maxime Petazzoni [EMAIL PROTECTED] wrote:
Since this tarball was not yet a release, does it still apply ? You're
getting self-contradictory here :)
It doesn't really matter, the point is that you've now got a situation
where there are multiple different tarballs with the same
On 12/8/05, Ruediger Pluem [EMAIL PROTECTED] wrote:
Furthermore you need a platform with a recent JDK. Of course our main
platforms should provide
this, but I think many of the platforms on the outer rim do not have this.
Converting the build system to Ant would cancel support for those
On 12/8/05, Brandon Fosdick [EMAIL PROTECTED] wrote:
FWIW, I've never seen that syntax before either.
That's C99 syntax. Older compilers, and C++ compilers, don't
generally support it.
-garrett
On 12/3/05, Ian Holsman [EMAIL PROTECTED] wrote:
I'd also like to brainstorm a better solution to running Rails/Django
applications inside of the httpd process than the SCGI/FastCGI solution
which most people use.
Out of curiosity, what do you think is wrong with the current FastCGI
method of
On 10/10/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Garrett Rooney wrote:
It just comes down to two questions. Do we want to offer the service,
and if so, what resource utilization do we want to optimize for?
If they are running an atom client, is it unreasonable to also force
On 10/10/05, Joshua Slive [EMAIL PROTECTED] wrote:
1. Do we really want people subscribing to mailing lists using atom
over http? This would consume way more resources than a standard
mailing list subscription (due to the polling nature of atom). I don't
have any evidence, but this worrys
So I'm playing around with mod_smtpd_queue_smtp, a module that has
mod_smtpd queue messages by forwarding them on to another smtp
server, and I ran into a little snag.
It appears that in older versions of apache2 (2.0.53 in this case)
conn-input_filters-ctx is NULL when smtpd_create_conn_rec gets
On 9/18/05, Colm MacCarthaigh [EMAIL PROTECTED] wrote:
These seem really unintuitive names; SMTP Queueing usually means
managing a spool and incremental backoff, ie the administration of a
mail queue.
But as far as I can tell, this code is all about SMTP forwarding (not
even relaying
I noticed that mod_smtpd is hardcoding /tmp as the location to write
temporary files that hold message contents while they're being
processed. It seems like this directory should be configurable, but
even if we want to make it use the system's temp dir, hardcoding /tmp
is not portable.
Attached
The set_id_string function in smtp_core.c currently triggers a warning
by assigning a const char * to smtpd_svr_config_rec::sId, which is
non-const.
I can't imagine we really want people messing with the contents of the
id string, so the best fix seems to be just making sId a const char *.
A
I spent some time today hacking together a mod_smtpd queue module that
forwards mail on to another smtp server.
The idea is that you can use mod_smtpd as your first line of defense,
making use of whatever fun filled spam blocking modules we eventually
come up with, but still use your existing
On 9/17/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+static int cleanup_socket;
This global worries me. How will it behave in a multithreaded MPM?
-garrett
Maxime Petazzoni wrote:
Hi,
As the Summer Of Code deadline approaches, I'd like to put mod_mbox to
the test in order to fix as many bugs as possible.
If you are willing to help, here follows some useful information :
- mod_mbox offers an AJAX browser (YY.mbox/browser) for dynamic
Maxime Petazzoni wrote:
2) The way you let the user page through different parts of a given
month is easy to miss. It took me a while to notice that the 1 2 3
4 links were up at the top. Adding next and prev links at the
top and bottom would solve that problem.
I've added Previous and Next
Rian Hunter wrote:
On Tue, 2005-08-23 at 11:04, Brian J. France wrote:
On Aug 23, 2005, at 12:18 AM, Jem Berkes wrote:
I noticed a couple posts about examples, there is now one as I have
committed all the RBL stuff I wrote. See:
Jem Berkes wrote:
+1, Jem since you have checked in the first plugin for mod_smtpd would
you mind creating a directory structure similar to this if it seems fine
to you?
I don't have a problem with it. Do I need a verification of my earlier
commit before I commit a new directory structure?
Jem Berkes wrote:
I don't have a problem with it. Do I need a verification of my earlier
commit before I commit a new directory structure?
What do you mean by verification?
In your earlier email you said Since the commit mail hasn't come through
yet (needs to be approved I imagine)
Oh,
Paul A Houle wrote:
I don't see end users clamoring for mod_ftp, or mod_snmpd. What's
the point of writing a squid replacement unless you can actually make
something better?
You seem to be under the mistaken impression that it's the users who
decide what the project does. Apache
[EMAIL PROTECTED] wrote:
Author: soc-rian
Date: Mon Aug 22 10:22:27 2005
New Revision: 235759
URL: http://svn.apache.org/viewcvs?rev=235759view=rev
Log:
mod_smtpd overhaul:
1. new structs: smtpd_conn_rec, smtpd_trans_rec
2. different i/o API: smtpd_getline, smtpd_respond_oneline,
[EMAIL PROTECTED] wrote:
Author: soc-rian
Date: Mon Aug 22 20:38:56 2005
New Revision: 239318
URL: http://svn.apache.org/viewcvs?rev=239318view=rev
Log:
Made smtpd_run_queue a RUN_ALL hook (so multiple plugins can handle the message)
This is another example of a change that makes numerous
Jem Berkes wrote:
Is this the right way or is there an example module I could compare
with?
I noticed a couple posts about examples, there is now one as I have
committed all the RBL stuff I wrote. See:
https://svn.apache.org/repos/asf/httpd/mod_smtpd/trunk/mod_smtpd_rbl/
This hooks into
Joe Schaefer wrote:
Rian Hunter [EMAIL PROTECTED] writes:
Either way, lacking header parsing in mod_smtpd is being
impractically pedant since probably 99% of SMTP transfers involve
messages in the RFC 2822/MIME formats. Although I think that maybe
there will be a plugin that wants data
Jem Berkes wrote:
When I looked at the expand function used by apr_hash.c it looked to me
like it keeps growing if you keep using 'set' with novel values. I was
thinking of using apr_hash in order to cache DNSBL queries for my module.
It would ensure rapid cache search but I am having trouble
Joe Schaefer wrote:
Garrett Rooney [EMAIL PROTECTED] writes:
Index: smtp_protocol.c
===
--- smtp_protocol.c (revision 232680)
+++ smtp_protocol.c (working copy)
[...]
+for (i = 0; i sr-extensions-nelts; ++i
On my Ubuntu linux box, the Apache2 apxs is installed as 'apxs2', and
the httpd binary is installed in the SBINDIR, not BINDIR, and is not
named httpd, so the current configure script can't find it. Here's an
updated version that makes two changes, first it lets you specify a full
path to the
I noticed that mod_smtpd seems to go to some lengths to avoid messing up
the global namespace, prefixing globally visible function names with
smtpd_ and so forth, but there seems to be one case where this isn't
done, process_smtp_connection_internal. This patch renames it to
So I'm having a little trouble getting mod_smtpd to compile, once I
fixed up the configure script to find apxs and apache correctly, I end
up with the following error:
$ make
/usr/bin/apxs2 -Wc,-Wall -o mod_smtpd.la -c smtp_core.c smtp_protocol.c
/usr/bin/libtool --silent --mode=compile gcc
I was just looking at the smtpd_request_rec in mod_smtpd, and I had a
few questions.
It seems that extensions and rcpt info is being stored in an apr_hash_t,
but it's only being keyed by integer. If you're only going to use ints
as keys, it seems like an apr_array_header_t would be more
Rian Hunter wrote:
Ah I didn't even realize the key allocation, I'll fix that. Thanks!
The reason I don't use an apr_array_t or similar is that I thought that
the number of elements in that type has to be fixed and can't be
automatically extended and allocated on the fly, If I'm wrong I
Garrett Rooney wrote:
Rian Hunter wrote:
Ah I didn't even realize the key allocation, I'll fix that. Thanks!
The reason I don't use an apr_array_t or similar is that I thought
that the number of elements in that type has to be fixed and can't be
automatically extended and allocated
Rian Hunter wrote:
This patch looks good but I have some questions. You seem to use the
returned pointers from apr_array_push without checking if they are
NULL. Even in apr_array_push, apr_palloc is used without checking for
NULL even though apr_palloc can definitely return NULL.
Because
[EMAIL PROTECTED] wrote:
Author: soc-rian
Date: Fri Aug 12 16:56:59 2005
New Revision: 232406
URL: http://svn.apache.org/viewcvs?rev=232406view=rev
Log:
More robuse apache version checking in configure
Modified:
httpd/mod_smtpd/trunk/configure
httpd/mod_smtpd/trunk/configure.ac
Would
Brad Nicholes wrote:
But on the other hand, there shouldn't be a reason why apr-util can't be
released at anytime regardless of why. If there is a linkage between
apr 1.2.0 and apr-util 1.2.0 that just means that they happen to be
released at the same time. There is nothing sacred about what
russell johnson wrote:
When I build the lucene4c library I get a liblucene4c.la that does not
look like any other .la file I have looked at and mod_mbox make does
not like it. Its trying to access the library when it goes to compile
mbox_search.c for the generate_index function. It gives me a
Maxime Petazzoni wrote:
Hi,
Last week, we've been discussing what mod_mbox should output (XML+XSLT
or XHTML?) and we seemed to settle our minds on a simple XHTML output
for the interface, plus of course the XML backend for AJAX
sub-requests.
Still, someone on the #apache-modules IRC channel
Rian Hunter wrote:
If there was going to be a large change to core, request_rec and friends
how about:
struct request_rec {
/* common stuff */
char *protocol_name; // different from r-protocol,
// but maybe doesn't have to be
struct ap_conf_vector_t
[EMAIL PROTECTED] wrote:
@@ -813,7 +813,7 @@
iov[0].iov_base = (void*)disk_info;
iov[0].iov_len = sizeof(disk_cache_info_t);
-iov[1].iov_base = dobj-name;
+iov[1].iov_base = (void*)dobj-name;
iov[1].iov_len = disk_info.name_len;
rv = apr_file_writev(dobj-hfd,
Paul Querna wrote:
Andr Malo wrote:
* [EMAIL PROTECTED] wrote:
Author: wrowe
Date: Mon Jun 6 09:22:16 2005
New Revision: 180333
URL: http://svn.apache.org/viewcvs?rev=180333view=rev
Log:
Sandbox of httpd/trunk/modules/ssl/ for OpenSSL 0.9.7 fips integration
development
Added:
Sander Striker wrote:
Ideas for a solution that doesn't involve waiting for APR-Util 1.2.0?
Yes. We could do the branch...
Heck, you don't even need to revert the commit to do that, just branch
from the revision before the change was made to trunk...
-garrett
Paul A. Houle wrote:
Also the stability of APR is going to matter. For a long time you
had to run Subversion on APR out of CVS and I'd often update svn and
then find that I had to update APR because they'd changed it so it
depends on the latest APR.
If APR is going to be reasonably
Graham Leggett wrote:
Hi all,
While building the latest trunk of httpd, I am getting these warnings at
the end of the build:
ld: warning multiple definitions of symbol _regcomp
/Users/minfrin/src/apache/sandbox/rpm/httpd-2.1.3/srclib/pcre/.libs/libpcre.a(pcreposix.o)
definition of _regcomp in
Jim Jagielski wrote:
Paul Querna wrote:
[EMAIL PROTECTED] wrote:
snip
httpd/httpd/trunk/modules/debug/.deps
httpd/httpd/trunk/modules/debug/Makefile
I thought these should both be generated, not checked into svn?
Yep, but how does one tell SVN to ignore them?? :/
svn pedit svn:ignore
Geoffrey Young wrote:
So, uhh, ping? Any comments other than i'm iffy and is there any
reason not to add it?
+1 (concept; implementation not verified)
here too. is this the most recent patch:
http://issues.eu.apache.org/bugzilla/attachment.cgi?id=12746
?
if so, I'll try and review the
Andy Armstrong wrote:
This isn't supposed to happen is it? :)
[EMAIL PROTECTED] apache]$ svn co \
http://svn.apache.org/repos/asf/httpd/httpd/trunk httpd-trunk
svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
svn: REPORT of '/repos/asf/!svn/vcc/default': 400 Bad Request
Paul Querna wrote:
An API to use as a starting point might be libdbi. Its public interface
is at http://libdbi.sourceforge.net/docs/programmers-guide/
They also have a set of documentation on the design of the Database
Driver's API at http://libdbi.sourceforge.net/docs/driver-guide/
I really
Cliff Woolley wrote:
On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote:
Allan - your last patches were to try to -wedge- the current
API into httpd. Can you share the patch just to fix APR?
Then we can start to comprehend scope. NO CASTS - just the
correct declarations in the first place.
Since
Geoffrey Young wrote:
So, uhh, ping? Any comments other than i'm iffy and is there any
reason not to add it?
+1 (concept; implementation not verified)
here too. is this the most recent patch:
http://issues.eu.apache.org/bugzilla/attachment.cgi?id=12746
?
if so, I'll try and review the
Geoffrey Young wrote:
Garrett Rooney wrote:
Justin Erenkrantz wrote:
--On Friday, September 17, 2004 1:07 PM -0400 Garrett Rooney
[EMAIL PROTECTED] wrote:
Could someone please take a look at bug 31228 in bugzilla?
It's just adding a new response code (226) which is defined in rfc3229.
I'm
André Malo wrote:
* Sander Striker [EMAIL PROTECTED] wrote:
I'm finally taking care of the conversion of httpd-* to SVN.
I'll follow up with instructions on how to pull new workingcopies,
etc etc. I'm looking for volunteers to actually write a page
for developers on where to get SVN and how to
Geoffrey Young wrote:
a little digging on my own at the time made it seem like solaris make is
really gmake, so between linux, solaris, and bsd a decent case was being
made that most unix make variants to support the syntax. of course, that
list of 3 was hardly exhaustive :)
Umm, on all the
Jean-Jacques Clar wrote:
Thanks for reporting the problem Norm,
The patch was submitted.
Is casting to (char *) really the right thing to do here? I mean why
not just make new const so the cast isn't needed at all? It seems like
a cast in this situation is a bit ugly...
-garrett
Jean-Jacques Clar wrote:
What about doing:
static const char *add_ignore_header(cmd_parms *parms, void *dummy,
- const char *header)
+ char *header)
{
cache_server_conf *conf;
char **new;
@@ -802,7 +802,7 @@
Justin Erenkrantz wrote:
--On Friday, September 17, 2004 1:07 PM -0400 Garrett Rooney
[EMAIL PROTECTED] wrote:
Could someone please take a look at bug 31228 in bugzilla?
It's just adding a new response code (226) which is defined in rfc3229.
I'm working on a module that implements a type
Nick Kew wrote:
On Thu, 16 Sep 2004, Paul Querna wrote:
In most of the Apache 2.0.XX releases, we have been using a CVS snapshot
of APR and APR-Util.
I would like to make it an official policy that for the 2.2 cycle, we
will never use a CVS snapshot of APR.
That makes httpd releases (relatively
Brian Akins wrote:
Or use HEAD where apr_off_t is an off64_t on i386
too.
any plan to backport this? All my counters are rolling over :(
That sounds like the kind of thing that would break binary
compatability, so I imagine it won't be backported.
-garrett
Geoffrey Young wrote:
hi all
I was just in garrett's APR talk here at oscon and he was mentioning the
APR_STATUS_IS_SUCCESS macro, which I found interesting since httpd only uses
it in a few places, opting for a direct comparison to APR_SUCCESS instead.
should we move to APR_STATUS_IS_SUCCESS in
William A. Rowe, Jr. wrote:
The initial thought was you might have LDAP success, OS status success,
and possibly multiple return codes that were considered successes.
Nothing was ever done with this.
What about the win32 definition of the macro:
#define APR_STATUS_IS_SUCCESS(s) ((s) ==
Greg Stein wrote:
On Wed, Jul 28, 2004 at 08:08:05PM -0400, Ryan Bloom wrote:
Basically, the macro is wrong and needs to be removed. The contract
that _all_ APR API's live up to is that on a successful result, they
must return APR_SUCCESS. The reason we chose to use 0 as success is
simple:
Yup.
Brian W. Fitzpatrick wrote:
Badda bing, badda boom. So my rsync fears were unfounded, it appears
it is trivial to mirror the repository?
I'm much more comfortable with that news. Is this more or less bandwidth
intensive than simply rsync'ing the repository files themselves?
Much much much much
101 - 191 of 191 matches
Mail list logo
