Problem and Solution to svn import
I had a brief conversation with some people on IRC tonight because my svn import was failing. The error was: subversion/libsvn_ra_dav/util.c:358: (apr_err=175002) svn: RA layer request failed svn: OPTIONS request failed on /foobar subversion/libsvn_ra_dav/util.c:343: (apr_err=175002) svn: The OPTIONS request returned invalid XML in the response: XML parse error at line 1: Extra content at the end of the document .. (/foobar) Notice that a 301 request is a permanent redirect, and the reason for this redirect is that I requested /foobar, not /foobar/. There are a couple of problems with this. 1) The error message isn't very good. 2) I got this even if I put /foobar/ in my request. I haven't done enough research to determine if my shell or the svn client was stripping off the trailing slash, but something is. I tend to think it is the shell. 3) This is a DAV resource and an OPTIONS request, thus it shouldn't be subject to mod_dir's redirection. The solution, luckily, is simple. Add the following to your Apache config file: BrowserMatch SVN redirect-carefully This instructs mod_dir to only do the redirect on GET requests. That should be mentioned in the docs somewhere. I have copied the httpd development mailing list, because this bug was specifically addressed over a year ago. I know, because I am the person who brought it to Greg's attention last time too. Mod_dir should not be redirecting non-GET requests by default. Ryan
Re: Problem and Solution to svn import
On Mon, 13 Jan 2003, Aaron Bannert wrote: On Monday, January 13, 2003, at 02:40 AM, Greg Stein wrote: 2) I got this even if I put /foobar/ in my request. I haven't done enough research to determine if my shell or the svn client was stripping off the trailing slash, but something is. I tend to think it is the shell. I don't think the shell would do that. It could be some canonicalization happening in the client, or something in Apache. Hard to know offhand. Zsh has been known to do things like this, and I bet Ryan is using zsh. Guilty as charged. :-) Ryan
Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator
On Sat, 21 Dec 2002, Cliff Woolley wrote:
On Fri, 20 Dec 2002 [EMAIL PROTECTED] wrote:
apr_brigade_create(bb, ...);
fill_brigade_with_data(bb, ...);
ap_pass_brigade(bb, ...)
ap_clean_brigade(bb, ...);
fill_brigade_with_more_data(bb, ...);
ap_pass_brigade(bb, ...);
This is perfectly legal for a handler to do.
No it isn't, because if ap_pass_brigade() makes it all the way down to the
core_output_filter, then after ap_pass_brigade_() returns, bb will have
been destroyed by the core_output_filter. I'm not necessarily saying
that's *right*, just that that's the case today.
That would be a pretty massive bug. I have both handlers and filters that
follow this pattern because it is supposed to work. The reason it works
in my testing, is that _most_ of the time the core_output_filter doesn't
destroy that brigade.
if (ctx-b) {
APR_BRIGADE_CONCAT(ctx-b, b);
b = ctx-b;
ctx-b = NULL;
}
This is where the magic happens. If the filter has already saved aside a
brigade for this request (or a previous request in this connection), we
merge the two and drop the new one (a potential memory leak if not for
pools).
As I have said all day, a filter cannot keep or destroy a brigade that it
didn't create. The creator of the brigade owns the brigade, and no other
filter can modify the brigade. They can modify the buckets in the
brigade, but they can't do anything to the brigade itself.
Ryan
Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator
On 20 Dec 2002, Brian Pane wrote: On Fri, 2002-12-20 at 21:37, [EMAIL PROTECTED] wrote: On 20 Dec 2002, Brian Pane wrote: On Fri, 2002-12-20 at 13:50, [EMAIL PROTECTED] wrote: Basically, if you received a brigade from a higher filter, you can only assume that it will survive a single trip down the filter stack. Right. And you also can't assume that the context that passed the brigade down the filter stack still exists by the time the brigade reaches the last filter. It's a safe assumption in httpd-2.0, where the brigade is passed as a synchronous function call, but it's not valid for apps in general (potentially including future Apache versions) where the brigade may be queued up for asynchronous processing by an I/O completion thread. Actually, it's not even a safe assumption in httpd-2.0. You have data from requests that originally lived in brigades allocated out of the request pool moved to brigades allocated out of the connection pool because the request pool is going away. But that just proves the point, the data must be moved from one brigade to another to change it's lifetime. That is part of the design of buckets and brigades. It is why the concat and split operations were written for maximum performance. We are talking about a couple of pointer assignments for the concatenation and a malloc and some pointer assignments for the split. And you're also talking about needing a pool from which you can do the alloc. With pool-based brigade allocation, there are two basic choices when allocating a new brigade during the split, and they both have problems: Um, you need a pool that lives at least as long as your filter. But that should make sense, because if you are going to do any memory allocation, you will need a pool in your filter. - Allocate from a connection pool. This is what httpd-2.0 does, but it's not a robust solution, given that connections can be very long-lived. And for non-http connections, like an app server connector, connections may live forever, so doing per-request allocations from a connection-level pool guarantees a memory leak. No, httpd-2.0 only uses the connection pool in filters that live as long as the connection. If that scope doesn't make sense, then you have to clear the brigade when you are done with it. Remember, we are talking about a couple of bytes for the size of the brigade. Even if it does leak until the end of the connection, it isn't a very big leak. It is a huge leak if you don't clear the brigade, but that is why we have brigade_clear. Pools just aren't a good match for the allocation needs of brigades. We happen to have been able to hack around many of the problems through liberal use of the copy the brigade into another pool with a more appropriate scope technique in httpd-2.0, but that's not a solution for apps in general. I'm really sorry, but I am sick of hearing this isn't a solution for apps in general. This is now the fourth time that I have asked for a clear description of _why_. I helped to design and write buckets and bucket_brigades. I understand them incredibly well. You seem to be unable or unwilling to give a clear description of the problem you are having. All you are doing is hand-waving saying that this might be a problem for some apps. Give a clear description please. Ryan
Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator
On 20 Dec 2002, Brian Pane wrote: On Fri, 2002-12-20 at 22:03, Cliff Woolley wrote: Can we at least agree to do one thing: release 2.0.44 *without* Brian's change. Okay with me. I am vetoing this change until I get a clear description of the problem it is solving. I have explained multiple times why it is a bad change, but I can't offer any other solutions until I know why it is needed. Then we can sort out the best course of action without delaying the entire release process on the stable branch. It might well be that the best course of action is to just fix the places in httpd that abuse brigades. But as Bill pointed out, what about third party modules? Ay caramba. FirstBill's patch should allow third party 2.0.x modules to work. It will not. If you _ever_ create a brigade with a NULL pool, you will have memory leaks. I dare say that every filter ever written will leak if the feature implemented with this patch is ever used. I have already posted one code segment in the core_output_filter that proves the memory leak exists. Trust me when I tell you that there are hundreds more, and some of them are in 3rd party modules that you don't control. +1 to moving brigades back into httpd, fwiw. +1 ++1, but they should go into an external library so that projects like serf have access to them. Happily, I don't have to worry about that. Ryan
Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator
On 21 Dec 2002, Brian Pane wrote: On Sat, 2002-12-21 at 07:58, [EMAIL PROTECTED] wrote: I'm really sorry, but I am sick of hearing this isn't a solution for apps in general. This is now the fourth time that I have asked for a clear description of _why_. I helped to design and write buckets and bucket_brigades. I understand them incredibly well. You seem to be unable or unwilling to give a clear description of the problem you are having. All you are doing is hand-waving saying that this might be a problem for some apps. Give a clear description please. Sorry, but that's just bogus. I've described repeatedly, and in detail, the reasons why we can't make bucket allocation dependent on pools. You keep posting objections along the lines of but we can just move a brigade into a pool of appropriate scope, when you know that's not a solution. No, that is a solution, in fact, it was part of the original design. What you've done is said The brigade may not live long enough, but you haven't explained how that is the case. You also haven't explained why moving the buckets to another brigade won't work. Which I have a very hard time believing, because that is how Apache works today. You also haven't answered the problem that even _WITH_ this change, you still need to move the buckets to a new brigade. At the end of the day, this change doesn't get you anything, because you _still_ have to do the brigade migration that you say you can't do. Ryan
Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator
What you've done is said The brigade may not live long enough, but you haven't explained how that is the case. This, too, is something that we've discussed already. Request cleanups can happen asynchronously relative to transmission of brigades created from the request. Having a pool cleanup trigger the destruction of a brigade in another thread is dangerous. The canonical solution is to migrate the data to a new brigade outside the pool before handing it off to another thread, which is fine as long as that doesn't create a need for another pool in the application (for the reasons noted above). You are talking about an application that is built around pools. If you want an async MPM that uses a single thread to write data to the network and multiple threads to generate the data, then your network I/O thread will need to have a pool. This pool will be very long lived (as long as the process is alive). You can allocate the brigade when the server starts, and just re-use it forever. You can have a pool of brigades that are continuosly re-used, or you can create a sub-pool for each call into your network write function. But, moving brigade allocation outside of pools isn't solving your problem and it is opening huge holes in the abstraction that was created. Screw it. Buckets and bucket brigades are being moved into a project that I no longer have any desire to work on. My veto stands for as long as the code is in an APR project. The change is wrong and it is dangerous. I have explained why in detail. Ryan
Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator
I am actually pretty sure that allocating brigades out of the
bucket_allocator is a VERY big mistake. In fact, I am close to asking
that change to be backed out because it is too dangerous.
When we first designed buckets and bucket brigades, we made one VERY clear
distinction. Bucket_brigades are allocated out of a pool, because that
stops us from leaking memory. Buckets shouldn't be allocated out of a
pool, because nobody knows which pool to allocate them from. Basically,
we said that in Apache, it is safe to just drop a bucket briade because
the pool cleanups will free the memory. It is not safe to just drop a
bucket, it must either be left on the brigade to be cleaned up by the
brigade_cleanup function, or it must be destroyed when it is removed from
the brigade.
By allocating bucket_brigades out of the bucket_allocator, we have removed
the protection that the pool cleanups used to give us. I may be wrong
about how the bucket_allocator works, but I don't believe I am.
Basically, this change will make Apache leak memory on some requests, and
it goes against the original design of buckets and bucket brigades. In
fact, allocating the brigades out of a pool was a requirement, because
some people at the meeting were afraid of memory leaks with bucket
brigades.
Ryan
On Fri, 20 Dec 2002, Bill Stoddard wrote:
If a pool is passed to apr_brigade_create, the brigade is allocated out of the
pool. If the pool is NULL, the brigade is allocated out of the bucket allocator.
We don't want a pool pointer hanging around in a brigade allocated out of the
bucket allocator. That's just asking for trouble. This patch makes how the
brigade is allocated, either out of the pool or out of the allocator, explicit.
Index: apr_brigade.c
===
RCS file: /home/cvs/apr-util/buckets/apr_brigade.c,v
retrieving revision 1.55
diff -u -r1.55 apr_brigade.c
--- apr_brigade.c 17 Dec 2002 19:16:39 - 1.55
+++ apr_brigade.c 20 Dec 2002 15:17:58 -
@@ -95,7 +95,9 @@
apr_pool_cleanup_kill(b-p, b, brigade_cleanup);
}
rv = apr_brigade_cleanup(b);
-apr_bucket_free(b);
+if (!b-p) {
+apr_bucket_free(b);
+}
return rv;
}
@@ -104,7 +106,12 @@
{
apr_bucket_brigade *b;
-b = apr_bucket_alloc(sizeof(*b), list);
+if (p) {
+b = apr_palloc(p, sizeof(*b));
+}
+else {
+b = apr_bucket_alloc(sizeof(*b), list);
+}
b-p = p;
b-bucket_alloc = list;
Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator
On 20 Dec 2002, Brian Pane wrote: On Fri, 2002-12-20 at 08:57, [EMAIL PROTECTED] wrote: I am actually pretty sure that allocating brigades out of the bucket_allocator is a VERY big mistake. In fact, I am close to asking that change to be backed out because it is too dangerous. When we first designed buckets and bucket brigades, we made one VERY clear distinction. Bucket_brigades are allocated out of a pool, because that stops us from leaking memory. Allocating brigades from a pool is often a design mistake. Brigades tend to outlive the transactions that produce them (especially in apps like http servers), and having a brigade disappear as a side-effect of a transaction pool's cleanup will cause problems elsewhere in the code. U, I don't believe that it is possible for a brigade to outlive the transaction that created it, especially not when you look at how brigades are used in the web server. Basically, a handler creates a brigade and passes it down the filter stack. Each filter in the line is then allowed to either concatenate that brigade to it's own brigade or keep sending it down the stack. At the bottom of the stack, the brigade must have been generated out of the connection pool, which by definition lives as long as the transaction that created it. Basically, if you received a brigade from a higher filter, you can only assume that it will survive a single trip down the filter stack. That is why all filters must create their own brigade to save data between calls. By allocating bucket_brigades out of the bucket_allocator, we have removed the protection that the pool cleanups used to give us. It's important to keep in mind just what sort of protection the pool-based brigade allocation offered. It allowed code that did this: bb = apr_brigade_create(...); apr_brigade_destroy(bb); APR_BRIGADE_INSERT_HEAD(bb, bucket); to work accidentally. I'm hesitant to call that protection. Give it up, that is a side-effect of pools, and it isn't the protection that we discussed when designing buckets and brigades. The protection that we are talking about is against memory leaks, which this change almost definately opened up in the web server. There is at least one place in the code where we drop a bucket brigade on the floor without cleaning it up, because we rely on the pool_cleanup to do it for us. This change removes that ability. Of course, you won't see that memory leak unless you make the correct request, but at some point, it will show up and you will have a hell of a time tracking it down. I can gaurantee that this change caused a memory leak. I know it did because Greg Stein and I argued over leaving a comment in the code that said essentially This would be a memory leak if the brigade were allocated out of a pool, but it is, so it is safe. We removed the comment, because the bucket_brigade design requires that all brigades are allocated out of pools. As for the bogus psuedo-code that you have above, that is pools for you. The same thing could be said for _ANY_ apr type. Try this sometime: apr_file_open(f, .); apr_file_close(f); apr_file_name_get(fname, f); You will get the correct value for fname without a segfault, and this will work on all platforms. The only way to fix that type of problem would be to make all destroy/close functions accept a pointer to the object that they are destroying/closing. Then, we could set the pointer to NULL, and the code above wouldn't work. We don't try to protect people from doing bone-headed things like using a structure after it has been destroyed, that is just a programmer not paying attention. However, the code that you have added removes the memory leak protection that brigades were supposed to provide for buckets. That is wrong, and thus the change should be removed. Ryan
Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator
and you will have a hell of a time tracking it down. I can gaurantee that this change caused a memory leak. I know it did because Greg Stein and I argued over leaving a comment in the code that said essentially This would be a memory leak if the brigade were allocated out of a pool, but it oops: s/were/weren't/ is, so it is safe. We removed the comment, because the bucket_brigade design requires that all brigades are allocated out of pools. Ryan
Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator
On 20 Dec 2002, Brian Pane wrote: On Fri, 2002-12-20 at 12:19, [EMAIL PROTECTED] wrote: As for this not working when the filter and handler are in different threads, of course it will. As long as the buckets are copied into a brigade that was allocated out of a pool that will still be alive when the filter is called, this will work just fine. In practice, it's not feasible to copy the buckets into a brigade allocated from a new pool. The connection pool isn't generally suitable, as it may be a long time before it is cleaned up, especially in the case of a proxy. Creating a response pool will work, but that doubles the amount of memory that the server must devote to a given request (one pool for request, one for response). That is why the core_output_filter destroys the bucket_brigade, cleaning up 90% of the memory used by the brigade (all the buckets) as soon as the data is written to the network. It is feasible to do the copy, because nothing else works. Regardless of how the brigade is allocated, the brigade that is passed to you doesn't belong to you. It belongs to the filter/handler that originally allocated it, and you can't gaurantee that it will still be around the next time your filter is called. It is very simple. If you are going to set-aside data in a filter, you _must_ copy the data to a brigade that you allocated. Nothing else is gauranteed to work. That is why copying/merging brigades was made so cheap. It is also why buckets aren't allocated out of pools. The change doesn't remove that ability at all. Both my patch and Bill's variant allow for a pool cleanup to destroy a brigade. Yes, but before it was mandatory, not it is optional. It can't be optional, it will cause a memory leak. It's wildly inaccurate to say it will cause a memory leak. A more correct characterization is, if the brigade is not allocated from a pool, its deallocation is the responsibility of the application. Same semantics as every other non-pool-based allocation API ever developed. It is not inaccurate at all. The current code has a memory leak if you don't pass a pool to the brigade_create function. You may not see it, but it is there. Apache is built around pools to remove these types of memory leaks. Filters, buckets, and bucket_brigades were designed to use pools to remove these kinds of memory leaks. Your change allows a brigade to be created that removes this protection. Because the rest of the server expects brigades to be allocated out of pools, you have created a memory leak. This isn't hand-waving. As soon as Bill's patch is committed, if you _ever_ pass NULL into the brigade_create function for the pool variable, you will have a memory leak. You can fix the leaks, but you have removed a the memory protection that the filters were designed around. The change isn't buying you anything at all, especially with Bill's proposed patch. All filters must assume that the bucket_brigade was allocated out of a pool, because otherwise they will be broken if it wasn't. That's only true for Apache 2.0. For later releases, it may be not only unnecessary but inadvisable to have brigades allocated from pools. Once you've allocated a brigade from a pool, for example, any subsequent split of that brigade will alloc from the same pool. If the split happens in a filter that's running in thread 2 while the request's handler is still running in thread 1, the colliding apr_pallocs will segfault. We almost certainly won't want to add a mutex to apr_palloc, because it would ruin the performance of lots of apps. But if the brigade allocations are done from a bucket allocator, it's quite feasible to add a mutex (or possibly a spinlock) into the bucket allocator without compromising performance. There are a lot of solutions to the problem you have described above. The easiest is to actually pass a pool to the brigade_split function, so that you know which pool is used to allocate the new brigade. Yes, using the bucket_allocator is another solution, but it is currently causing seg faults, and when that problem is fixed it will cause memory leaks. To fix the memory leaks, you will need to ensure that all brigades are destroyed, which means that the code will become more complex (if only to track when brigades are created and destroyed). The pools are used so that we don't have to track resources this closely, that is, in fact, their main benefit. Again, please explain the problem that you are trying to solve in detail instead of describing your solution. It is just possible that other people on this list will have an idea that will solve your problem while not causing the side-effects that the current change will cause. In the mean-time, I am -0. leaning towards -1 for this change, because of the side-effects that it has already demonstrated and those that I have detailed as lurking around the corner. This change actually makes it harder to
Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator
On Fri, 20 Dec 2002 [EMAIL PROTECTED] wrote: On 20 Dec 2002, Brian Pane wrote: On Fri, 2002-12-20 at 08:57, [EMAIL PROTECTED] wrote: I am actually pretty sure that allocating brigades out of the bucket_allocator is a VERY big mistake. In fact, I am close to asking that change to be backed out because it is too dangerous. When we first designed buckets and bucket brigades, we made one VERY clear distinction. Bucket_brigades are allocated out of a pool, because that stops us from leaking memory. Allocating brigades from a pool is often a design mistake. Brigades tend to outlive the transactions that produce them (especially in apps like http servers), and having a brigade disappear as a side-effect of a transaction pool's cleanup will cause problems elsewhere in the code. U, I don't believe that it is possible for a brigade to outlive the transaction that created it, especially not when you look at how brigades are used in the web server. Basically, a handler creates a brigade and passes it down the filter stack. Each filter in the line is then allowed to either concatenate that brigade to it's own brigade or keep sending it down the stack. At the bottom of the stack, the brigade must have been generated out of the connection pool, which by definition lives as long as the transaction that created it. Basically, if you received a brigade from a higher filter, you can only assume that it will survive a single trip down the filter stack. That is why all filters must create their own brigade to save data between calls. Just to be very clear about why this true. Imagine a handler that does this: apr_brigade_create(bb, ...); fill_brigade_with_data(bb, ...); ap_pass_brigade(bb, ...) ap_clean_brigade(bb, ...); fill_brigade_with_more_data(bb, ...); ap_pass_brigade(bb, ...); This is perfectly legal for a handler to do. However, this means that any filter that wants to save the data in this brigade for use later, must copy the buckets to their own brigade. If they try to just save a pointer to the brigade, they won't have the data they expect on the second call. The brigade will still exist, but the data will be wrong. For this reason, all filters must move the buckets to their own brigade, which means that a brigade cannot outlive the transaction that it was created for. Essentially, the filters mitigate the brigade lifetimes. Ryan
Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator
On Fri, 20 Dec 2002, Aaron Bannert wrote: On Friday, December 20, 2002, at 01:26 PM, [EMAIL PROTECTED] wrote: The pools are used so that we don't have to track resources this closely, that is, in fact, their main benefit. They were also added for performance reasons, but I don't know if this was a side effect or the main reason. Delaying freelist management until after a response gives a huge performance gain from the perspective of an http client. yes, performance was a reason in httpd, but in APR, it really came down to convenience. Ryan
Re: [PATCH] Update to Brian's patch to allocate brigades out of thebucket allocator
On 20 Dec 2002, Brian Pane wrote: On Fri, 2002-12-20 at 13:50, [EMAIL PROTECTED] wrote: Basically, if you received a brigade from a higher filter, you can only assume that it will survive a single trip down the filter stack. Right. And you also can't assume that the context that passed the brigade down the filter stack still exists by the time the brigade reaches the last filter. It's a safe assumption in httpd-2.0, where the brigade is passed as a synchronous function call, but it's not valid for apps in general (potentially including future Apache versions) where the brigade may be queued up for asynchronous processing by an I/O completion thread. Actually, it's not even a safe assumption in httpd-2.0. You have data from requests that originally lived in brigades allocated out of the request pool moved to brigades allocated out of the connection pool because the request pool is going away. But that just proves the point, the data must be moved from one brigade to another to change it's lifetime. That is part of the design of buckets and brigades. It is why the concat and split operations were written for maximum performance. We are talking about a couple of pointer assignments for the concatenation and a malloc and some pointer assignments for the split. The change to stop allocating the brigade out of a pool is a mistake and I am asking for it to be reverted, or for a clear description of the problem that it is solving. I have asked for this description three times now, and I still don't understand what exactly you are trying to achieve and why it can't be achieved with the old code. Ryan
Re: [PATCH] Update to Brian's patch to allocate brigades out ofthe bucket allocator
On Fri, 20 Dec 2002, William A. Rowe, Jr. wrote: At 08:33 PM 12/20/2002, Brian Pane wrote: On Fri, 2002-12-20 at 13:50, [EMAIL PROTECTED] wrote: Basically, if you received a brigade from a higher filter, you can only assume that it will survive a single trip down the filter stack. Right. And you also can't assume that the context that passed the brigade down the filter stack still exists by the time the brigade reaches the last filter. It's a safe assumption in httpd-2.0, where the brigade is passed as a synchronous function call, but it's not valid for apps in general (potentially including future Apache versions) where the brigade may be queued up for asynchronous processing by an I/O completion thread. No, it simply will have to be valid. Not that the context will be bound to a specific thread (it won't), and not that the content will be living in a given context. Please read my response to Brian, it isn't a valid assumption in httpd-2.0. Bottom line, we can't break it till we push out APR 1.0. This leaves a very useful question. Do buckets/brigades remain in apr-util with the release of 1.0? We've just proven that the concept is both very apr and very httpd centric. There is no reason we should burden apr with the 'learning curve' of redesigning this code. I suggest we consider the benefits of pulling buckets/brigades from apr-util with the 1.0 release of the apr library, and move that code back into httpd if we plan to keep abusing it this way. apr and apr-util should be repositories for proven concepts, if not always proven code. If we are still redesigning, something is wrong. I consider this an incorrect statement. New concepts should be welcome anywhere. My question is more basic. Is the bucket/brigade concept useful outside of the web server/web client libraries that are being discussed? If so, then they should stay where they are. If not, then move 'em back into the httpd project. Of course, I don't believe that apr-util is a useful library currently, so that could be why I am against keeping buckets and brigades in it. That library won't be useful until it has more holding it together than These are concepts that were useful in Apache, so we exported them. Ryan
[PATCH] new include in mod_include.h
mod_include.h requires util_filter.h, but it doesn't include it. This is fine for Apache itself, because everywhere that mod_include is used, util_filter is already included. However, for people extending mod_include, this means that they must include util_filter. Here is a patch to fix it. Index: modules/filters/mod_include.h === RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.h,v retrieving revision 1.33 diff -u -d -b -w -u -r1.33 mod_include.h --- modules/filters/mod_include.h 6 Jun 2002 04:58:43 - 1.33 +++ modules/filters/mod_include.h 18 Dec 2002 16:30:14 - @@ -59,6 +59,7 @@ #ifndef _MOD_INCLUDE_H #define _MOD_INCLUDE_H 1 +#include util_filter.h #include apr_pools.h #include apr_optional.h Ryan
Re: [patch] perchild MPM bug fixes (+ open problem)
Consider the case where an admin configures the server to listen on www.foo.com:8080, but he never assigns a child process to listen to that port. If you just don't accept the connections, the user will hang forever. If every child process, however, actively closes the sockets that it can't serve, then the client won't even be able to connect. That's a good point too. What I was thinking was to add an artificial limitation that you can't share an IP:port pair across two different uid/gid's since that's the only case you want to pass a connection. That limitation should already exist, although it may not. That limitation doesn't exist either in the documentation or in the implementation. I figured that was part of the point of connection passing. I know it's also useful for passing between the siblings for a particular uid/gid also, but why not just require 1 child per uid/gid and then not worry about connection passing at all? A couple of reasons. Remember first of all that the more threads per process, the less stable your server. This is because if a module seg-faults, the whole process dies. For that reason, many admins will want to have multiple child processes with the same uid/gid to create some failover. The second reason, however, is that the file descriptor passing is meant to solve the case of multiple Name-based Vhosts on the same ip:port all with different uid/gid requirements. In that case, you will have multiple child processes all listening to the same ip:port, but you will need to do the file descriptor passing. Closing the file descriptors of ip:port combinations that can't be served is a great optimization, but that is all it is, an optimization for the non-Name-based vhost case. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: [patch] perchild MPM bug fixes (+ open problem)
On Thu, 17 Oct 2002, Johannes Erdfelt wrote: Ryan, I've CC'd you on this just to let you see the patch. If you don't want me to involve you in this, please accept my apologies and let me know and I won't CC you in any further patches. I have no problem being CC'ed on patches, although for the most part, I am unlikely to respond. In this case however, I will. I want to say that this is great. I have reviewed the patch and the logic, and it all looks fantastic. I'm really glad that the MPM is making progress. I will also provide a possible solution to the one problem that you were unable to solve. :-) Problem 4: Occasionally, when a request needs to be passed to another process, it will hang until another connection is accepted. perchild uses the same process accept mutex that the other MPM's seem to need. This results in serialization of all accept() calls as is the intent of the mutex. The problem is that another process might have acquired the mutex from the process that actually needs the mutex to hit accept() and see the passed request. This isn't normally a problem because all processes accept connections on all listening ports. The problem in this case is the fact not all processes accept connections on the per process unix domain socket to pass connections around, for obvious reasons. Solution: I don't have one :) I'm not sure what the best way of solving this is. I don't fully understand the semantics of the process accept mutex yet. Any suggestions? There is only one solution that I can see for this, unfortunately, it is a rather big change. :-( The first step, is to migrate the perchild MPM to the same model as the worker MPM, where one thread accepts requests and puts them in a queue, and the rest of the threads remove the requests from the queue, and actually serve them. I've been meaning to do this for a long time, but I never got around to it. Once that is done, the solution to this problem is easy. Every child process needs to have two acceptor threads. The first accepts on the TCP socket, and the second accepts on the Unix Domain Socket. For the TCP socket, the thread should just use the same accept_mutex that it is using now. However for the Unix Domain Socket, each thread that is accepting on the socket should just use apr_file_lock to lock the socket before accepting. This should remove the starvation that you are seeing, because each socket will have it's own lock. This is really great work, I hope that it gets applied ASAP. Ryan
Re: [patch] perchild MPM bug fixes (+ open problem)
As long as you are doing all this work, there is one more thought that I have been meaning to implement, but that I never got around to. Currently perchild doesn't work with SSL, because of when the request is passed off, and how SSL works. The easy solution to this, is to have the child processes close the sockets for any requests that they cannot handle. This will also improve the chance that a request won't be passed if you have vhosts with different ports. Consider the following: VHost www.foo.com:80 AssignChildPerUidGid rbb rbb /Vhost Vhost www.foo.com:81 AssignChildPerUidGid foo foo /VHost There is no reason for the foo/foo child process to be listening on port 80. Just a thought for how to get SSL to work. I actually have a patch for this already :) Although I implemented it only as an optimization and not because of the issue with SSL. I hadn't tried to do SSL yet. I'd imagine this SSL limitation will have to be clearly documented since it may not be obvious to everyone. Actually, as long as you have a patch to do this, then SSL should just work, and no docs should be necessary. :-) Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: [patch] perchild MPM bug fixes (+ open problem)
On Mon, 21 Oct 2002, Johannes Erdfelt wrote: On Mon, Oct 21, 2002, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: What I was thinking was to add an artificial limitation that you can't share an IP:port pair across two different uid/gid's since that's the only case you want to pass a connection. That limitation should already exist, although it may not. That limitation doesn't exist either in the documentation or in the implementation. I figured that was part of the point of connection passing. I know it's also useful for passing between the siblings for a particular uid/gid also, but why not just require 1 child per uid/gid and then not worry about connection passing at all? A couple of reasons. Remember first of all that the more threads per process, the less stable your server. This is because if a module seg-faults, the whole process dies. For that reason, many admins will want to have multiple child processes with the same uid/gid to create some failover. The second reason, however, is that the file descriptor passing is meant to solve the case of multiple Name-based Vhosts on the same ip:port all with different uid/gid requirements. In that case, you will have multiple child processes all listening to the same ip:port, but you will need to do the file descriptor passing. Well, that's what I said before, but you implied that the limitations should prevent this. :) yeah, you're right, I wasn't thinking when I wrote that. Sorry. Closing the file descriptors of ip:port combinations that can't be served is a great optimization, but that is all it is, an optimization for the non-Name-based vhost case. Yes. This brings it back to what I was saying before, you can't pass SSL connections, so as a result, you can't share an SSL port across two uid/gid's. So this should be documented somewhere, or enforced in the server (which may be difficult because of the layering), so people don't do that :) You don't need that doc. In order to share an ip:port combination across child processes, you need to be using name-based vhosts. SSL doesn't support name-based vhosts today, so there is no new docs required. Of course, if my patch to provide Upgrade support goes in, then you will be able to share ip:port combinations that support SSL across child processes. So, the docs really aren't necessary. Anyway, I think I understand the path to follow now. I'm going to implement the necessary fixes to make perchild finally usable. Great! Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Final patch for a long time.
The recent conversations on this list have made me finally realize that I
have been here too long. I need a project that is not the Apache web
server. So, this is my good-bye. I will be unsubscribing from the Apache
web server development lists in the next day or two. I will still be
involved in APR development work, so I will still be reachable at
[EMAIL PROTECTED]
There are two projects that I started that have not been finished. I
would hope that one of two things would happen to both of them. Either
somebody else should pick them up and run with them, or they should be
removed from the server.
The first project is the Perchild MPM. It basically works, but there are
bugs.
The second is SSL upgrade. I have the patches, they haven't been
committed yet. I have attached them at the bottom of this message. The
reason they haven't been committed, is that I don't have a client to test
them with, and I haven't had time to create one. The responses are
correct I have checked them in plain text. The place that bugs most
likely exist, is the actual upgrade code that does the handshake. This is
an important feature, and I would really like to see it in 2.0.
It has been a lot of fun the last four years working on Apache, but I have
been here too long, and it isn't fun anymore. It isn't worth doing if it
isn't fun.
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
? build.err
? build.log
? output.log
? sslupgrade.patch
? modules/new
? srclib/apr/APRVARS
? srclib/apr/build.err
? srclib/apr/build.log
? srclib/apr/newpoll2.tar.gz
? srclib/apr/i18n/unix/Makefile
? srclib/apr/test/build.err
? srclib/apr/test/build.log
? srclib/apr/test/garg
? srclib/apr/test/testall
Index: modules/ssl/mod_ssl.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/mod_ssl.c,v
retrieving revision 1.72
diff -u -d -b -w -r1.72 mod_ssl.c
--- modules/ssl/mod_ssl.c 14 Oct 2002 04:15:57 - 1.72
+++ modules/ssl/mod_ssl.c 15 Oct 2002 16:49:07 -
@@ -105,7 +105,7 @@
/*
* Per-server context configuration directives
*/
-SSL_CMD_SRV(Engine, FLAG,
+SSL_CMD_SRV(Engine, TAKE1,
SSL switch for the protocol engine
(`on', `off'))
SSL_CMD_ALL(CipherSuite, TAKE1,
@@ -274,7 +274,7 @@
return 1;
}
-static int ssl_hook_pre_connection(conn_rec *c, void *csd)
+int ssl_init_ssl_connection(conn_rec *c)
{
SSLSrvConfigRec *sc = mySrvConfig(c-base_server);
SSL *ssl;
@@ -283,40 +283,14 @@
modssl_ctx_t *mctx;
/*
- * Immediately stop processing if SSL is disabled for this connection
+ * Seed the Pseudo Random Number Generator (PRNG)
*/
-if (!(sc (sc-enabled ||
- (sslconn sslconn-is_proxy
-{
-return DECLINED;
-}
+ssl_rand_seed(c-base_server, c-pool, SSL_RSCTX_CONNECT, );
-/*
- * Create SSL context
- */
if (!sslconn) {
sslconn = ssl_init_connection_ctx(c);
}
-if (sslconn-disabled) {
-return DECLINED;
-}
-
-/*
- * Remember the connection information for
- * later access inside callback functions
- */
-
-ap_log_error(APLOG_MARK, APLOG_INFO, 0, c-base_server,
- Connection to child %ld established
- (server %s, client %s), c-id, sc-vhost_id,
- c-remote_ip ? c-remote_ip : unknown);
-
-/*
- * Seed the Pseudo Random Number Generator (PRNG)
- */
-ssl_rand_seed(c-base_server, c-pool, SSL_RSCTX_CONNECT, );
-
mctx = sslconn-is_proxy ? sc-proxy : sc-server;
/*
@@ -368,6 +342,44 @@
return APR_SUCCESS;
}
+static int ssl_hook_pre_connection(conn_rec *c, void *csd)
+{
+SSLSrvConfigRec *sc = mySrvConfig(c-base_server);
+SSLConnRec *sslconn = myConnConfig(c);
+
+/*
+ * Immediately stop processing if SSL is disabled for this connection
+ */
+if (!(sc (sc-enabled == TRUE ||
+ (sslconn sslconn-is_proxy
+{
+return DECLINED;
+}
+
+/*
+ * Create SSL context
+ */
+if (!sslconn) {
+sslconn = ssl_init_connection_ctx(c);
+}
+
+if (sslconn-disabled) {
+return DECLINED;
+}
+
+/*
+ * Remember the connection information for
+ * later access inside callback functions
+ */
+
+ap_log_error(APLOG_MARK, APLOG_INFO, 0, c-base_server,
+ Connection to child %ld established
+ (server %s, client %s), c-id, sc-vhost_id,
+ c-remote_ip ? c-remote_ip : unknown);
+
+return ssl_init_ssl_connection(c);
+}
+
static apr_status_t ssl_abort(SSLFilterRec *filter, conn_rec *c)
{
SSLConnRec *sslconn = myConnConfig(c);
@@ -572,6 +584,15 @@
Re: apache test suite?
look at httpd-test. Ryan On Sat, 12 Oct 2002, David Burry wrote: Has anyone worked on an Apache test suite? You know, like how many things have a make test that runs all sorts of tests... or perhaps a separate package that runs tests... I might be interested in starting one but would rather build upon other's work if some of it has already been done... Dave -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
On Sat, 12 Oct 2002, Glenn wrote:
Glenn, thanks I had deleted Jim's message and I was re-creating it. You
made it so I didn't have to. :-)
On Sat, Oct 12, 2002 at 05:11:29PM -0400, Jim Jagielski wrote:
This is going to sound like a grumpy old man talking, but it's sounding
more and more like that 2.0 tree is considered, by many of the
developers, little more than a playground to hack around in. There
seems very little regard for end users or developers (API changes
with every release... yeah, so what.). Are people hacking 2.0
(or 2.1) because it's fun to do and a neat project, or is there
a desire that *people actually use the code*?
I'm certainly not saying that we ship broken or stupid code simply
to get it out, but certainly people should be aware that, when all
is said and done, isn't the whole idea of ASF projects is that
people are encouraged to use them? Yeah, we should allow the API
to grow and mature, but having it constantly change means, at
a very core level, we have no idea what it should be doing or
how it should be doing it. [...]
I think there is a much easier way to satisfy everybody and stay in the
2.0 tree. The problem right now, is that the MMN isn't granular
enough. All we know, is that we broke binary compatibility. But, we
don't know where it was broken, which means that all modules must be
re-compiled. But, let's take the auth changes as an example. We had to
bump the MMN with these changes, because of what was done. But, the only
modules that were affected, were auth modules. That means that anybody
who has a filter oesn't need to re-compile.
If we modularize the MMN, and provide a way for module authors to query
the MMN at a granular level, most of the MMN bumps become much more
trivial. Let me explain what I mean.
#define MAJOR_MMN 0
#define AUTH_MMN 000
#deifne FILTER_MMN 000
...
#define MMN MAJOR_MMN,AUTH_MMN,FILTER_MMN
int check_auth_api(int module_number)
{
if GET_AUTH_MMN(module_number) AUTH_MMN) {
return false; /* May want to just exit with an error here */
}
return true;
}
Now, and auth module just needs to call check_auth_api() in
register_hooks. If it returns false, the module needs to exit, or things
will fail. If it returns true, then all is good.
If the module doesn't call any of the individual check_*_aupi() functions,
then the best we can do is to check the whole thing the way we do now.
The advantage to this, is that it allows us to bump the MMN when we need
to, but that bump is less likely to affect as many people.
I see how to implement the whole thing if this will satisfy people.
Ryan
Re: segfault in mod_negotiation.c
On 12 Oct 2002, Jeff Trawick wrote:
Gregory (Grisha) Trubetskoy [EMAIL PROTECTED] writes:
--- mod_negotiation.c Fri Aug 9 15:21:57 2002
+++ mod_negotiation.c.new Sat Oct 12 15:47:36 2002
@@ -2881,7 +2881,7 @@
int res;
int j;
-if (r-finfo.filetype != APR_NOFILE
+if (!r-finfo || r-finfo.filetype != APR_NOFILE
|| !(ap_allow_options(r) OPT_MULTI)) {
return DECLINED;
}
what does it mean to say !r-finfo when finfo is a structure, not a pointer?
Better question, how in the world is this seg faulting?
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
Re: cvs commit: httpd-2.0/server log.c
On 13 Oct 2002 [EMAIL PROTECTED] wrote: wrowe 2002/10/12 20:25:04 Modified:server log.c Log: Some errors are impossible to fathom, without the user knowing certain base numbers. This patch introduces (EAP ##): Eap message for the EAP errors, (OS ##): Message for modestly numbered os errors (under 10) and hex (OS 0x): Message for huge errors, which generally have bit-flag meanings and are usually represented in hex. What in the world is an EAP error? Rather than do this, I would much rather have the OS errors normalized, and all other erros retain their original values. Ryan
Re: Auth: Start the httpd-2.1 branch finally?
On Sat, 12 Oct 2002, Jim Jagielski wrote: [EMAIL PROTECTED] wrote: In all of these cases, there was a developer or three, who created a CVS tree either in their home directories, or in the main CVS area. They made the major changes that they wanted to see made, and then they announced the changes to the list, and invited people to help them make the projects better. Except for the fact that in all the above cases, the branch being deviated from was a solid, robust and reliable codebase. It was *time* to start a new branch, knowing that the current codebase was, at a very deep level, very robust and baked. Is 2.0? *That* is my only concern regarding a 2.1 branch. It leaves 2.0 in a not-quite-there state. It's the idea that 2.0 is dropped so work can progress on 2.1. PS: I don't see this as another Shambhala situation, by the way. I am less concerned about *if* we should do a 2.1 branch, and more concerned with *how* it is being done. In the message above, I don't think you are advocating a 2.1 branch. It sounds like you believe that we should take the time to finish 2.0 before moving on. Am I right in interpreting it that way? Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
I finally figured out why a 2.1 branch bothers me so much. It isn't being done the way it should be done. When apache-nspr was created, it wasn't because there was a big discussion on-list and Dean decided to go do the work. When apache-apr was created, it wasn't because Bill, Manoj, and I started a big discussion and then did the work. When apache-2.0 was created, it wasn't becasue Dean explained what he wanted to do to apache-apr and then did the work. When httpd-2.0 was created, Roy didn't explain what he was going to do, and then go do the work. In all of these cases, there was a developer or three, who created a CVS tree either in their home directories, or in the main CVS area. They made the major changes that they wanted to see made, and then they announced the changes to the list, and invited people to help them make the projects better. One of three things happened with these trees. Either they were picked up as the new development tree and the old tree was lost. Or, they were completely ignored. Or, they were tried and rejected for specific reasons. With the fabled 2.1 branch, people want to have a discussion about what is going to go into it, then they want to fork, and then they want to start writing code. That is a completely backwards approach. If you have a major change that you want to make to 2.0, make the change, either in a sandbox, or in a copy of the current tree. Then, invite people to look at what you did. Once we see how big the change is, we can decided if 1) We like the change to you made, and 2) if it is big enough to warrant a bump to 2.1. There is no push to branch 2.1, becasue there is no code that warrants a branch. Personally, if you are going to write cod, I suggest just creating a CVS repository in your home directory, and allowing people to collaborate there. If the code is accepted, it is easy to move it into the main CVS area. In fact, of all of the examples above, I don't thik anybody started working in the main CVS area. I know Dean didn't with either apache-nspr or apache-2.0. I think Roy had a basically working copy before httpd-2.0 was created, and Billo and I worked without CVS until Manoj started helping us. Bottom-line: Talking about a branch before there is any code is completely bogus. None of us know what is going to be in 2.1. I know I have some ideas for how to do the filesystem abstraction that I want to play around with. But I also know that a bunch of other people have ideas too. Which one will be the foundation for the work? I don't know, and I can't until we see some actual code. Why should one person be allowed to put their code in the httpd-2.1 branch? They shouldn't. I will personally be doing some pwork in /home/rbb/cvs either on www.apache.org or www.rkbloom.net in the next few weeks. Once I have a working prototype, I will open it up to people to look at and play with. Only then can we decide if it belongs in 2.1 or 2.0. As for the Auth patches, BTW, the code was created first, and then it was decided to put it in 2.0. That was the way it should be done. However, Justin, it would be really cool if you could create a simple Perl script that takes an old config and updates it to a new one. It may just be the LoadModule lines, but automating that work would be really nice for our users. That idea was thrown out in a conversation I had with Will. I think it was his idea, but I honestly can't remember. Ryan On Sat, 12 Oct 2002, Justin Erenkrantz wrote: --On Friday, October 11, 2002 10:59 PM -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I'm calling for a consensus opinion that the mod_auth changes are simply too radical to introduce into a current version. We keep treating the GA tree as a development branch. Many newcomers (with less than a couple of years here in httpd land) and a very few old timers persist in doing so. We had a vote before the changes were checked in. I don't know what else you'd like to have done. It was the stated consensus of the group that these changes go into 2.0 not a 2.1 - knowing full well that it could break directive compatibility. So, I think the notion that some rule was violated is absurd - I believe everything was done in the mystical 'Apache way.' The one thing that I dislike about a 2.1 is that we've stated that we can't force any developer to go to the new version. Other committers have stated that they won't develop or forward-port fixes to 2.1. And, some developers might not back-port fixes from a 2.1 to 2.0. That's not going to be helpful to our users. My hope is that when we go to a 2.1, all developers believe it is time and 2.0 should be closed. Right now, I don't believe that is the case. -- justin -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
On Sat, 12 Oct 2002, Justin Erenkrantz wrote: --On Friday, October 11, 2002 10:00 PM -0700 Brian Pane [EMAIL PROTECTED] wrote: I don't have a strong opinion about the authn redesign, but I do have one change in mind that would fit well in 2.1: async write support. And async read support, but that may take a lot longer. My belief is that you should design and code up the async support and then we can deliberate about where it should go. These changes shouldn't be held up by the fact that we don't have a 2.1 yet. Lead with the code - once the code is written or we have a plan of attack, we can find a home for it. IMHO, that's the only way things happen around here. -- justin Damn Justin, I just spent three pages saying this exactly. Run for the hills everybody, Justin and I agree. There is bound to be a flood or some event of biblical proportions somewhere. :-) Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
I am so sick of this conversation. 2.0 isn't done yet. It won't be done until it is actually stable, and it isn't currently stable. But, you have worn me down. Create a new fscking tree, populate it and begin working on it. I will be finishing 2.0. And yes, this is very harshly worded. We have had this conversation multiple times, and everytime, the same people want to branch, and the same people want to stabilize the server. If you can't deal with taking the time to stabilize the server, then branch the tree. But, do not even think of saying that the MMN of 2.0 can't change just because you have created a new tree. Ryan
Re: Auth: Start the httpd-2.1 branch finally?
On Fri, 11 Oct 2002, William A. Rowe, Jr. wrote: At 11:21 PM 10/11/2002, [EMAIL PROTECTED] wrote: I am so sick of this conversation. 2.0 isn't done yet. It won't be done until it is actually stable, and it isn't currently stable. Fine. That's no reason to deprecate modules mid-stream. Was it a good choice to rename mod_access to mod_auth_host? Well, I suppose it makes much more sense, from our view. But from a common sense administrators view, that's OS Coders fsking around with naming for the sake of changing the names. And it does them no practical good. Then put the old modules back in. They still work, they just don't work as well. But, you have worn me down. Create a new fscking tree, populate it and begin working on it. I will be finishing 2.0. My analogy was bad. Let me rephrase. 1.3 is mixed, baked and now cooling down. 2.0 is mixed, still baking and won't cool down for a while. I'm asking that we move Justin's changes to 2.1 and start mixing the danged thing already. And let that not stop anyone from fixing bugs!!! When the right fix is a straightforward change to some borked code, apply it to both trees at once. If the right fix is to redesign the server, axe a module, or whatever, then lets do that in a 2.1 tree. In other words, stop all new development in 2.0. Nope. It's bogus, the server is ready for it. And yes, this is very harshly worded. We have had this conversation multiple times, and everytime, the same people want to branch, and the same people want to stabilize the server. If you can't deal with taking the time to stabilize the server, then branch the tree. But, do not even think of saying that the MMN of 2.0 can't change just because you have created a new tree. Of course the httpd project will always have cross purposes by the coders and other contributors. Everyone here has itches to scratch. That's GOOD! If we didn't, this project would be dead long ago. I'm asking for Justin''s revamp to come out of 2.0. I'm suggesting it go immediately into a new tree. If that is reasonable to people, please say so. If I'm being unreasonable, please point that out. I'm suggesting that Justin's change doesn't stabilize the tree. You want us all rowing with you in the same direction. That isn't open source development within the Apache framework. That's Joes' Project on sourceforge, or the Linux model. It's not the Apache way. I absolutely hate the phrase the Apache way. I hate it for a simple reason. Nobody knows what the hell it is. HAve you noticed yet that people throw it around when they want things to work their way? I haven't asked everybody to do what I say. I personally have a couple of projects that I care about, and I am ignoring the rest of the BS. But I worked too damned hard, as did a lot of other people, to move on to 2.1 just when people are starting to port their modules to 2.0. You are being unreasonable. This was disucsssed, you were a part of the discussion. It was decided to put this stuff into the 2.0 tree. Justin updated the docs, there was some small discussion over how to deal with having docs for both sets of modules. That hasn't been resolved yet. So rather than argue, let's provide the tree for folks to explore their new efforts. Won't be in anyone's way. In fact, it will improve the stability of the GA branch, which is something I believe ALL of us desire. Because it won't have an impact on the 2.0 tree. I and others will continue to improve Apache 2.0 to solve people's problems. All it will do, is confuse users, and make it harder to fix problems. Like I said, feel free to branch, but nobody should even try to state that becasue 2.1 was started 2.0 can't have an MMN bump. 2.0 is in it's infancy as a GA server. There are still a lot of changes that can and should happen to it. That is a part of the product lifecycle. deal with it. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
On Sun, 13 Oct 2002, Greg Stein wrote: On Sat, Oct 12, 2002 at 06:18:41PM -0400, [EMAIL PROTECTED] wrote: ... I think there is a much easier way to satisfy everybody and stay in the 2.0 tree. The problem right now, is that the MMN isn't granular enough. All we know, is that we broke binary compatibility. But, we don't know where it was broken, which means that all modules must be re-compiled. But, let's take the auth changes as an example. We had to bump the MMN with these changes, because of what was done. But, the only modules that were affected, were auth modules. That means that anybody Woah! Totally not true. The auth changes DID NOT affect MMN. And they DID NOT affect other auth modules. All the focus around this stuff is a sensitive issue. Let's not make it worse with misinformation. I know it wasn't intentional, but let's not let it spread. The auth change *added* stuff. It absolutely did not change any APIs, so there was no need for an MMN bump. That said, there probably should have been a minor bump so that code can test whether an API is present. But minor bumps are totally righteous. No problem with those. OK. My bad. I am completely incorrect, and I take the blame for that. Sorry. ... If we modularize the MMN, and provide a way for module authors to query the MMN at a granular level, most of the MMN bumps become much more trivial. Let me explain what I mean. +1 on the concept. Along these lines, I've wanted to go into the new provider stuff that Justin added and add a provider-version number. That would allow a person to register a particular version of a provider. This is especially important because I want to make big changes to the mod_dav API, but (today) that would imply an MMN bump. If I can introduce a provider API version, then changes to the mod_dav interface would not kill the whole server -- just DAV providers. I would prefer one API for the provider/MMN check, so I will try to throw something together this week. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote: At 11:40 AM 10/13/2002, Jim Jagielski wrote: [EMAIL PROTECTED] wrote: In the message above, I don't think you are advocating a 2.1 branch. It sounds like you believe that we should take the time to finish 2.0 before moving on. Am I right in interpreting it that way? +++1 Then I want to clarify ... you both object to the statement that developers within HTTP should be free to work on what they want. Obviously, you are both stating that we should not introduce 2.1 anytime real soon now. Therefore, you are stating that developers are not free to introduce radical new code at the present moment, and only things that fit within Apache 2.0 [subject to perpetual debate over what exactly what fits within 2.0] are open for community development efforts. Bill, I'm sorry, but you aren't reading the e-mails that have been sent. You want to branch 2.1 so that people can make radical changes. We are saying feel free to create patches with radical changes. Once people can see the patches, we can decide if they belong in 2.1, 2.0, or if we don't want them in Apache at all. If you want to create the patches in a community, then create a CVS repository in your home directory. Please don't call it httpd-2.1, because you don't get to decide that your efforts are 2.1, that is for the group to decide. We are stating quite clearly, that you are free to branch and show us what you want to do in 2.1. What we aren't willing to do, is create a 2.1 tree where everybody is supposed to do their work. There is a good chance that the first few attempts at a 2.1 tree will fail and won't ever see the light of day. Please finally go back and read the messages where people have explained why they don't want to branch. Also, as for the auth stuff, you seem to have completely ignored that Greg has offered a solution that might create backwards compat for the users with the new auth work. You are so focused on getting a 2.1 branch, that you are ignoring any other solutions to the problem that you have raised. Ryan Please see my other post about offering a 2.1 working branch within the httpd-2.0 tree, maintained only by the 2.1 contributors, and please offer your opinions of that solution. This would apply to docs as well, since folks interested in documenting the demise of mod_access and introduction of mod_authn/authz_foo modules would be free to proceed, while not interfering with the primary httpd-2.0 docs, and picking up revisions and changes by merging the ongoing activity within the httpd-2.0 tree. Bill -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote: At 03:33 PM 10/13/2002, [EMAIL PROTECTED] wrote: On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote: At 11:40 AM 10/13/2002, Jim Jagielski wrote: [EMAIL PROTECTED] wrote: In the message above, I don't think you are advocating a 2.1 branch. It sounds like you believe that we should take the time to finish 2.0 before moving on. Am I right in interpreting it that way? +++1 Then I want to clarify ... you both object to the statement that developers within HTTP should be free to work on what they want. Obviously, you are both stating that we should not introduce 2.1 anytime real soon now. Therefore, you are stating that developers are not free to introduce radical new code at the present moment, and only things that fit within Apache 2.0 [subject to perpetual debate over what exactly what fits within 2.0] are open for community development efforts. Bill, I'm sorry, but you aren't reading the e-mails that have been sent. You want to branch 2.1 so that people can make radical changes. We are saying feel free to create patches with radical changes. Once people can see the patches, we can decide if they belong in 2.1, 2.0, or if we don't want them in Apache at all. You haven't read a single email on this thread. The ENTIRE POINT of this thread is that we have a radical change. Auth. Two Bills and who knows whom all else may concur that we can't reasonably force this change into 2.0 for docs and upgrade reasons. So we have a radical change. I proposed we create 2.1 to incorporate auth. I've read them all. We discussed this before the patch was incorporated into the release. The majority do NOT believe it is radical enough to warrant 2.1. No matter how many times you ask for 2.1 for the auth work, the majority don't believe it warrants it. Please finally go back and read the messages where people have explained why they don't want to branch. Also, as for the auth stuff, you seem to have completely ignored that Greg has offered a solution that might create backwards compat for the users with the new auth work. Greg's post does not address the Docs issue. I'm waiting for someone to offer constructive feedback. As I wrote in my response to Justin, I did try to wrap my brain around documenting both pre and post auth in the same /docs-2.0/ tree. It didn't make any sense. Perhaps someone else can do better. I will write the docs to handle both. I commit to having them done by the end of the week. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Auth: Start the httpd-2.1 branch finally?
On Sun, 13 Oct 2002, Justin Erenkrantz wrote: --On Sunday, October 13, 2002 9:36 PM -0400 Joshua Slive [EMAIL PROTECTED] wrote: One more note: I'd like to see the rename of mod_access reversed. That just seems like a gratuitous change that hurts users and doesn't really help developers. Could you please explain why breaking out the authorization (authz) components in a similar fashion to authentication (authn) is a gratuitous change? Justin, he said the name change was gratuitous, not the change itself. I believe mod_authz_host is a much better name for mod_access. It indicates that this module is only dealing with authorization based on the remote host components. mod_access can mean lots of things, but the fact that it was solely restricted to hostnames wasn't obvious to me from the original module name. -- justin It may not have been obvious to you, but anybody who has been using Apache for the last few years has always known this. I happen to agree, the name change does make more sense, but it wasn't necessary for the patch. Please change the name back. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: apache 2.0.43: %b not showing bytes sent but bytes requested
On 12 Oct 2002, Bojan Smojver wrote: On Fri, 2002-10-11 at 18:58, David Burry wrote: This should also be a concern for anyone who's using mod_logio to charge for bandwidth, because customers should be concerned about some serious overcharging going on here! Only if you charge for outgoing bandwidth. On incoming bandwidth, I think it should be pretty accurate because it won't count what wasn't received. Anyway, I think what's causing this problem is the fact that mod_logio calculates the length of all brigades that are ready to be sent out. If the sending gets interrupted in the middle, the whole thing gets reported, instead of just the buckets/brigades that were actually sent out. Maybe I should use (AP_FTYPE_NETWORK + 1) instead of (AP_FTYPE_NETWORK - 1) for the output filter (i.e. count after the sending, not before). I'll give it a try... That won't work. The core_filter will return without calling your filter. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: apache 2.0.43: %b not showing bytes sent but bytes requested
What we are learning here is simple. We need to do the counting in the core_output_filter. If that means adding a field to the conn_rec, or somehow getting the request_rec in the core_output_filter doesn't matter. The count needs to be done in the core_output_filter, by tallying the amount of data actually written. Ryan On 12 Oct 2002, Bojan Smojver wrote: Nope, that doesn't work. The number is always zero. Bojan On Sat, 2002-10-12 at 12:22, Bojan Smojver wrote: Anyway, I think what's causing this problem is the fact that mod_logio calculates the length of all brigades that are ready to be sent out. If the sending gets interrupted in the middle, the whole thing gets reported, instead of just the buckets/brigades that were actually sent out. Maybe I should use (AP_FTYPE_NETWORK + 1) instead of (AP_FTYPE_NETWORK - 1) for the output filter (i.e. count after the sending, not before). I'll give it a try... -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Closing bugs.
Please do not mark bugs FIXED unless the problem is actually solved. I have noticed that bugs against experimental modules are often being closed with the explanation that the module isn't really ready for production use yet. That isn't a good reason to close a bug. The bug still exists, but people trying to fix the modules won't find the bug if it is marked FIXED. Bugs should only be marked FIXED if there is code or docs committed that actually resolved the problem. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: sockets and such
On Thu, 10 Oct 2002, Randall Stewart wrote: Hi: I am working on getting apache2 (2.0.43) to be able to listen on SCTP sockets as well as TCP. This involves a small amount of work expanding the socket_t to have a protocol field. It should be possible to do this without any core changes, as an initial implementation. One of the goals for Apache 2.0, was to allow the socket to be abstracted out of the server by a module. If you create your own module, that implements listening for an SCTP socket, everything should just work. For an example of how to do this, take a look at perchild and how I inserted the Unix domain socket into the listen_rec list. /* XXX this REALLY needs to be uncommnted, but it is causing problems */ right before a apr_table_do()... in pass_request() Now in my poking around I found what the problem was.. on the recvmsg() side of the socket in receive_from_other_child() the iov[] addresses were all set to 0. i.e. iov[0].iov_base = headers; ... iov[0].iov_base = request_body; This is most likely the problem.. I have uncommented the line and fixed the above.. Not sure how to test it yet... but I will let you know if I see any problems from it.. THANK YOU! I forgot about that bug, but this does look like the problem. I spent all of my time looking at pass_request(), and completely ignored receive_from_other_child(). :-( Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Apache and Unix domain sockets
uOn Thu, 10 Oct 2002, Bojan Smojver wrote: This might sound silly, but can one make Apache 2.0 listen to a Unix domain socket instead of a TCP socket? I looked through the code that has to do with sockets and it seemed as if that was not possible at this point. But I might have missed something... It is possible. You will need to use connection-oriented UDP sockets, but it can be done. For an example of how to make the server listen on non-TCP sockets, look at the perchild MPM, and how it deals with Unix Domain sockets. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: sockets and such
On Thu, 10 Oct 2002, Randall Stewart wrote: [EMAIL PROTECTED] wrote: On Thu, 10 Oct 2002, Randall Stewart wrote: Hi: I am working on getting apache2 (2.0.43) to be able to listen on SCTP sockets as well as TCP. This involves a small amount of work expanding the socket_t to have a protocol field. It should be possible to do this without any core changes, as an initial implementation. One of the goals for Apache 2.0, was to allow the socket to be abstracted out of the server by a module. If you create your own module, that implements listening for an SCTP socket, everything should just work. For an example of how to do this, take a look at perchild and how I inserted the Unix domain socket into the listen_rec list. Hmm. yes this was one of the things I have looked at.. it is not quite as easy as that though.. The problem is in the fact that SCTP and TCP both use SOCK_STREAM : The TCP-Style interface (which is prefered here since apache expects the listen/accept model) uses the same type. The only difference is the protocol type (third argument to socket()). Now of course all socket calls in apache2 use a ,0); as the last arg.. this is a base problem. I think the right fix is to add a protocol type and maintain this... I'm sorry, I wasn't clear. Because the server only opens the listening socket in one place, the easiest way to do this, is to completely ignore Apache. Just write a module that opens the SCTP socket, and add it to the listen_rec list. From that point on, whenever Apache receives a request over an SCTP socket, it will just use it. A more long-term approach, is to integrate SCTP into APR, but I don't really know how prevalent SCTP is. If it only works on a small set of platforms, then we are less likely to integrate it into APR, because by it's very definition, it isn't portable. There is also the problem that the only source I have found for SCTP is under the GPL. I am getting there.. but I still have a problem.. and this may be a config issue.. drats that I did not compile it unchanged first :-0 I suppose I will have to go re-download a clean copy.. I get everything working.. the TCP and SCTP sockets open up to listen for HTTP requests.. but then somewhere along the line the server does its exit.. I guess after forking its children.. but at that point the SCTP socket closes.. so do the TCP ones as well :-0 Thus I suspect a problem in my config... This doesn't sound like a config problem. The Apache parent process starts, and then forks to make itself a daemon. The forked process then reads the config, and sets itself and the children up. That first child should never die, and that is where the socket is opened. It sounds like there is some other problem here. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Whopsie on Darwin/Mac OS X 10.2.1... :-(
On Mon, 7 Oct 2002, Pier Fumagalli wrote: On 7/10/02 21:45, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: At 03:27 PM 10/7/2002, Sander Temme wrote: Your HEAD probably uses the glibtool(ize) installation on your local box, which on 10.2 by default is 1.4.2. The tarball was built using the FreeBSD libtool, which is 1.3.4. This version did not know about Darwin yet and will not create any sort of shared library on this platform. The solution is building the tarball with a more recent version of libtool. Maybe Apache should fail more conclusively if the user wants .so modules and the build system can't do them, but that's a different question from getting the functionality to work. I think the ASF roll environment should bump its libtool. I doubt Darwin is the only platform that would benefit from that. This is my doing. Suggestion; could you offer a patch to build/httpd_roll_release that warns the RM that the version of buildconf is too stale? Checking against 1.4.2 would be a good-thing(TM) indeed, but doesn't guarantee that on certain platforms (such as darwin, where the mainstream libtool port doesn't work) this will not break things again... We've been playing the libtool game since I started building 2.0. At one point or another, it broke things (I remember AIX as well), and as far as I know, noone has ever been able to get a patch incorporated into the main tree (I mean, removing a couple of is not a big deal, right?)... We can't keep libtool on our CVS as it's GPLed, let's just keep it off somewhere, apply the patches _we_ need, and keep our machines updated with _our_ version which works _for_us_... Right? I've got a better idea. Let's just get jlibtool doing enough so that we can use it everywhere. :-) Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
SSL Upgrade support.
Just a heads up. I wrote SSL Upgrade support this weekend for Apache 2.0. In my (currently) limited testing, things look pretty good. We currently respond to all requests correctly, and I think I have the SSL filters being inserted properly. However, there are no clients that I know of that support this feature yet. My hope was to have time to add it to Neon this weekend, but it didn't happen. I won't commit the Apache code until I can test it with a client, so if anybody wants to help me implement the client side, or if anybody knows of any clients that already support this, please let me know. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: DO NOT REPLY [Bug 9181] - Unable to set headers on non-2XXresponses.
Please do not close bug reports without entering some kind of information about why it is being closed. Ryan On 4 Oct 2002 [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9181 Unable to set headers on non-2XX responses. [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: cvs commit: httpd-2.0/server core.c
On 1 Oct 2002 [EMAIL PROTECTED] wrote:
gstein 2002/10/01 09:24:41
Modified:server core.c
Log:
Fix bug in the default handler. POST is not allowed on regular files.
The resource must be handled by something *other* than the default
handler.
-1. This is going to break PHP. PHP is a filter now, which means that
the page is served by the default_handler. Since PHP requests are allowed
to use POST, this is now broken.
As I said before, the bug is in mod_dav, and must be fixed there.
Ryan
Revision ChangesPath
1.207 +8 -0 httpd-2.0/server/core.c
Index: core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.206
retrieving revision 1.207
diff -u -r1.206 -r1.207
--- core.c 30 Sep 2002 23:43:18 - 1.206
+++ core.c 1 Oct 2002 16:24:41 - 1.207
@@ -3259,6 +3259,14 @@
return HTTP_NOT_FOUND;
}
+/* we understood the POST method, but it isn't legal for this
+ particular resource. */
+if (r-method_number == M_POST) {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ This resource does not accept the POST method.);
+return HTTP_METHOD_NOT_ALLOWED;
+}
+
if ((status = apr_file_open(fd, r-filename, APR_READ | APR_BINARY, 0,
r-pool)) != APR_SUCCESS) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r,
--
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
SSL tests failing.
I just tried to make a minor change to the server, and test it to ensure that it didn't break anything. Unfortunately, the test suite is currently broken with regard to SSL. I haven't had time to look into this yet, and probably won't until Tuesday at the earliest. Ryan -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: SSL tests failing.
On Mon, 30 Sep 2002, Justin Erenkrantz wrote: --On Monday, September 30, 2002 4:43 PM -0400 [EMAIL PROTECTED] wrote: I just tried to make a minor change to the server, and test it to ensure that it didn't break anything. Unfortunately, the test suite is currently broken with regard to SSL. I haven't had time to look into this yet, and probably won't until Tuesday at the earliest. Do you have any details? The SSL tests pass here. ssl/basicauth is skipped because it doesn't know about the new auth modules - that's easy enough to fix - will change that now. -- justin Failed Test Status Wstat Total Fail Failed List of Failed ssl/env.t 28 14 50.00% 15-28 ssl/require.t 52 40.00% 2, 5 ssl/varlookup.t 72 72 100.00% 1-72 ssl/verify.t 31 33.33% 2 8 tests and 6 subtests skipped. *** server localhost:8529 shutdown !!! error running tests (please examine t/logs/error_log) Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: [PATCH] add simple ${ENV} substitution during config file read
On Thu, 26 Sep 2002, Dirk-Willem van Gulik wrote:
In the department of scratching old itches - any strong objections to me
adding the following patch which allows one to do things like
# httpd.conf
ServerRoot ${HOME}/apache
Port ${PORT:=80}
ErrorDocument 500 Please contact ${CUSTOMER}
and then
[EMAIL PROTECTED] PORT=1234 ./apachectl start
as few, if any, people use ${FOO} constructs in their configuration files
today - the change is rather harmless.
But I've found this useful (since 1.3.9 :-).
Objections ?
Just the one that Dean has been harping on for years. The config file is
not a language, nor should it be. If you want things like macro
substitution or env variable substitution, then use a pre-processor. The
web server shouldn't have to worry about stuff like this.
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
Re: UDP ?
Serving content over UDP does work with 2.0. It takes some work, but all of the required features are there. However, I modified Apache a couple of years ago to serve HTTP over UDP, it doesn't work. The only reason to serve over UDP with Apache, is to serve a different protocol. IF you would like a quick little module that creates UDP sockets, and gets us serving over UDP, I could probably hack something together in a day or two. Of course, it will be a couple of months before I get to it. I just don't have the time for programming that I used to. :-( Ryan On Wed, 25 Sep 2002, Gregory (Grisha) Trubetskoy wrote: Has there been any consideration given to supporting UDP, to allow things like HTTP over UDP as described here: http://ftp.ics.uci.edu/pub/ietf/http/draft-goland-http-udp-01.txt The idea of HTTP over UDP may seem irrational, but UPnP (which is the protocol that is supposed to let your microwave oven discover and control your dvd player) relies on exclusively on HTTPU, and I was curious whether httpd could be rigged to be upnp capable. I saw an earlier short thread about UDP, but could quite figure out where it ended. Grisha -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: How Do I Create A Per-Worker Pool?
On Wed, 25 Sep 2002, Ian Holsman wrote: Leonardo Javier Belén wrote: I think I have a question to ask associated to this thread: How can I implement a global pool of objects. Let me say it better, I want a global pool of database connection, first because I have a limited number of connections and second, because I want to be able to dominate the dbms accesses. All developed as an ansi C apache module, but I thing is the same. I'm running Apache 1.3. Is this the same thing? Leonardo Javier Belen. AFIP-AR Have a look at apr_reslist.c in the apr-util/misc directory. apr_reslist.c actually won't work in this case. He is trying to use Apache 1.3, which means that the connections would need to be shared across processes. In general, it just isn't worth doing a connection pool with 1.3, because of the overhead of the process model. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: instdso.sh - basename confusion
On Tue, 24 Sep 2002, Dirk-Willem van Gulik wrote: And then try to install (on Solaris) a module as a .so: ../a2/bin/apxs -i -n mod_foo mod_foo.so I would suggest looking at HEAD rather than 2.0.40 as I made changes to instdso.sh to explicitly handle this case. instdso.sh will now emit a warning rather than error out if you pass it a non-.la file. -- justin Nice ! Any way of -not- making it need the .la; or being able to do without it if it is lost ? If you already have the .so, why would you use apxs? The whole point of apxs, is to build the module, and get it into the source tree. If all you are using apxs for, is to edit the config file, I would suggest that there are better tools available for that job. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: [PATCH] core_output_filter
On Sat, 21 Sep 2002, Ryan Morgan wrote: Thats a good point, I didn't think about that case. Maybe the safe way is to just add a check for APR_TIMEUP? I would much rather check for EAGAIN than continue to add more codes that could mean failure. Or put more succinctly, there are far more ways that this could fail than there are ways it could succeed. Call out the success cases, not the failure cases. Ryan
Re: Seg fault in mod_dav.
On Wed, 18 Sep 2002, Justin Erenkrantz wrote: On Wed, Sep 18, 2002 at 07:47:14PM -0700, Greg Stein wrote: Okay... I've checked in the change. I'd suggest tossing 2.0.41 and roll this fix into a 2.0.42. (I'm not suggesting using HEAD for 2.0.42) Something like: $ cvs tag -r APACHE_2_0_41 APACHE_2_0_42 # copy the tag $ cvs tag -F APACHE_2_0_42 modules/dav/main/mod_dav.c Then roll and release 2.0.42. Yeah, the only other gotcha I've seen with 2.0.41 is that the CHANGES file is wholly incorrect. Namely that the aaa rewrite isn't in .41. +1 for including the mod_dav fix and calling it 2.0.42. -- justin +1 for .42 And to make it official, .41 should be classified as an alpha release. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Seg fault in mod_dav.
On Thu, 19 Sep 2002, William A. Rowe, Jr. wrote: At 10:05 AM 9/19/2002, [EMAIL PROTECTED] wrote: +1 for .42 Agreed here, no signs of trouble. And to make it official, .41 should be classified as an alpha release. All tarballs rolled are Alpha until otherwise released as Beta candidates, which remain Beta candidates until they are released as GA code. yes, and I was stating my desire that .41 never move beyond alpha. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: hep
Done Ryan On Thu, 19 Sep 2002, Jon Travis wrote: Hep pease unscripe !! -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Seg fault in mod_dav.
More details. YAY First, a stack trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 18642)] 0x403cf42f in dav_method_options (r=0x8123470) at mod_dav.c:1762 1762if ((err = (*vsn_hooks-get_option)(resource, elem, body)) (gdb) where #0 0x403cf42f in dav_method_options (r=0x8123470) at mod_dav.c:1762 #1 0x403d3424 in dav_handler (r=0x8123470) at mod_dav.c:4507 #2 0x08064db8 in ap_run_handler (r=0x8123470) at config.c:194 #3 0x0806533d in ap_invoke_handler (r=0x8123470) at config.c:401 #4 0x080624c6 in ap_process_request (r=0x8123470) at http_request.c:288 #5 0x0805e28b in ap_process_http_connection (c=0x811d528) at http_core.c:293 #6 0x0806d138 in ap_run_process_connection (c=0x811d528) at connection.c:85 #7 0x0806d3e3 in ap_process_connection (c=0x811d528, csd=0x811d458) at connection.c:207 #8 0x08063a4a in child_main (child_num_arg=0) at prefork.c:696 #9 0x08063b08 in make_child (s=0x80996f0, slot=0) at prefork.c:736 #10 0x08063bfe in startup_children (number_to_start=5) at prefork.c:808 #11 0x08063f0c in ap_mpm_run (_pconf=0x8097950, plog=0x80c19f8, s=0x80996f0) at prefork.c:1024 #12 0x0806958c in main (argc=4, argv=0xbba4) at main.c:643 #13 0x402943c1 in __libc_start_main () from /lib/libc.so.6 Next, the value of vsn_hooks: gdb) p vsn_hooks $1 = (dav_hooks_vsn *) 0x0 Finally, the config and the problem: Location /svn/repos Dav svn SVNPath /svn # snipped for brevity, not the cuase /Location The problem is that I was requesting: svn import http://www.rkbloom.net/svn mumble Notice that the config is /svn/repos, but the command is /svn. There is no /svn, so I should have gotten a 404 back. Ryan On Wed, 18 Sep 2002, Greg Stein wrote: On Wed, Sep 18, 2002 at 06:49:48PM -0400, [EMAIL PROTECTED] wrote: I don't know if this is in .41 because I haven't had time to test it yet. But, HEAD of mod_dav has an annoying seg fault. Basically, if you send an OPTIONS request for a location that isn't configured for DAV, the module seg faults. I have traced it far enough to know where it is happening, but the fix shouldn't require that information. Basically, the mod_dav handler should be ensuring that Dav has been given a provider for the current location before it tries to handle the request. If this bug exists in 2.0.41, then -1 for GA. I will try to test .41 later tonight, and to create a patch at the same time. I'm not seeing that problem: [gstein@roshi test]$ telnet localhost 8080 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. OPTIONS /icons/ HTTP/1.0 host: roshi.collab.net HTTP/1.1 200 OK Date: Wed, 18 Sep 2002 23:26:28 GMT Server: Apache/2.0.41 (Unix) DAV/2 Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Length: 0 Connection: close Content-Type: httpd/unix-directory Connection closed by foreign host. [gstein@roshi test]$ (I'm not sure that the above code is exactly 2.0.41, but something close) I'm updating to HEAD to check this out some more. Can you provide a backtrace for what you're seeing? Cheers, -g -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: mod_custom_log exits too late?
On 17 Sep 2002, Brian Pane wrote: On Mon, 2002-09-16 at 23:32, Justin Erenkrantz wrote: On Mon, Sep 16, 2002 at 09:46:47AM -0700, Brian Pane wrote: I disagree entirely. There's no need to let the API keep changing continuously, especially not for the sake of correctness. All of our competitors provide API stability. And as a result, people who develop modules for, say, IIS or IPlanet don't need to worry about their code breaking with every maintenance release. I think you're missing a huge point here. You *cannot* tell IIS or iPlanet that their APIs suck. Of course you can. And if you're a big enough customer, your server vendor will take your comments seriously enough to improve APIs in the next major release. What a responsible vendor will not do, however, is break all their other customers' systems in the next maintenance release just because one customer didn't like the function signatures. You probably can't even fix problems in their servers. You're stuck. You *can* tell us that our APIs suck and provide patches on ways to improve - especially for 2.0. Sure. And we have an obligation to users and third party developers to take constructive input and work it in to future releases in a manner that won't break people's systems. I don't think we are going to end up agreeing. I also don't think it matters. The reality is that you can't get to binary compat without doing 1 of two things. 1) Wait until the API is ready. 2) Litter the API with multiple functions that all do the same thing in slightly different ways. #2 is bogus, and all it does is to make the API harder to understand. If you can somehow manage to acheive binary compat without doing either of these, then cool. Otherwise, I would much rather see us choose option #1, becuause it is less detrimental in the long run. The example that has been given so far, is the ap_filter_*_register functions, which had a function pointer added. The suggestion was that this could have been done by adding another function. Yes, it could have. But, you wouldn't be able to get rid of those functions until 3.0. As proof, we had functions from 1.2 that weren't removed until the 2.0 release. Sorry, but API pollution doesn't excite me. Between API pollution and breaking binary compat, I choose the latter. Commercial companies can't do this, because users don't have the source. Our users do, and we can do this. If a commercial company wants to modify Apache to provide binary backwards compat, they can do that, and as long as they remain within a single major version, the work shouldn't even be that hard. The other option, is for us to create an ap_compat.h header again. This would provide us with a level of source compat. I don't know why we haven't been keeping that file up to date. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: auth stuff still broken
On Tue, 17 Sep 2002, William A. Rowe, Jr. wrote: I was thinking about this. What about -eliminating- the mod_authn_default and mod_authz_default, merging them into mod_auth, and moving the directives from mod_auth_basic and mod_auth_digest into the common mod_auth. Mod_auth would further include all of the hooks, and be the common module that all other mod_auth_foo, authn and authz modules require. Does that make any sense? I'm certain you will have users misconfigure the 'backstop' modules (_default flavors) resulting in insecure servers. If the 'backstop' _default auth handlers are always loaded as part of the core mod_auth, users will have far fewer problems. I almost like this, but I wouldn't put it mod_auth. I would put them in the core. The core server has always been the location for our default functions. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: auth stuff still broken
On Tue, 17 Sep 2002, Greg Stein wrote: On Tue, Sep 17, 2002 at 10:26:02AM -0700, Aaron Bannert wrote: On Tue, Sep 17, 2002 at 01:00:44PM -0400, Ryan Bloom wrote: Does that make any sense? I'm certain you will have users misconfigure the 'backstop' modules (_default flavors) resulting in insecure servers. If the 'backstop' _default auth handlers are always loaded as part of the core mod_auth, users will have far fewer problems. I almost like this, but I wouldn't put it mod_auth. I would put them in the core. The core server has always been the location for our default functions. +1 for the core, or at least a module that's always statically compiled (which is easy to do with the .m4 macros we have). Well... as long as core means modules/http/. But since our running of auth hooks comes from server/, then this stuff could prolly go there as well. IMO, it sucks that our core server knows about HTTP authentication and authorization. In general: sure, this stuff makes some sense in the core rather than default modules. It should be in server, please. Remember that many protocol modules use those same hooks to do their authentication. Perhaps this re-org should also try to abstract that stuff out. But, regardless of whether the HTTP-part of the authenticatio is abstracted, please leave the hooks in the /server directory. At some point, it would be really nice to be able to build Apache without the /http module. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
RE: Tagged and rolled 2.0.41
I would also recommend a new tarball with the timestamp tweaked. Something like so: $ tar xzf httpd-tar.gz $ touch .../ssl_expr_parse.c $ tar czf httpd-tar.gz httpd-... That's gonna affect the tarball's MD5 signature tho. And the PGP signatures. Do I hear objections against that? Just on the basic premise that the tarball has been released. At this point, it is available for users. If we are going to create new tarballs, then must have a new name. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: [PATCH]: Update request in connection based filters
You don't want to do this. A connection based filter is connection oriented. By definition, it has no concept of a request. While this might make sense for HTTP, other protocol modules will have a much harder time with this change. Ryan On 18 Sep 2002, Bojan Smojver wrote: Justin, After mucking around a bit with what you suggested, this seemed like the straightforward thing to do. Not sure how things would work on internal redirects etc. Can you please have a look. I'm sure it's naive, but so am I (for now :-) Bojan -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: [PATCH]: Update request in connection based filters
On Wed, 18 Sep 2002, Bojan Smojver wrote: I understand. But isn't the ap_read_request HTTP specific given it's creating the request and all? In other words, if protocol is HTTP, we let connection filter know about the request. If not, we don't. That to me sounds exactly the same as your suggestion. I must be missing something... The problem is that the filters aren't HTTP specific. If you make this change, then the filters will be written to take advantage of the f-r field in connection level filters. Since that field doesn't make sense in non-HTTP requests, modifying the filter_rec so that it is there is a mistake. Think about it this way. If you add the request_rec to the core_output_filter, and that filter is modified to use it, then all protocol modules must ensure that the request_rec is added to the filter, even if it doesn't make sense. If you make it optional to put the request_rec in the filter_rec, then you will be making it much harder to write filters. Ryan Bojan Quoting [EMAIL PROTECTED]: You don't want to do this. A connection based filter is connection oriented. By definition, it has no concept of a request. While this might make sense for HTTP, other protocol modules will have a much harder time with this change. Ryan - This mail sent through IMP: http://horde.org/imp/ -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: cvs commit: httpd-2.0/support htpasswd.c
On Tue, 10 Sep 2002, William A. Rowe, Jr. wrote: At 01:36 AM 9/10/2002, Justin Erenkrantz wrote: On Tue, Sep 10, 2002 at 03:00:51AM -, [EMAIL PROTECTED] wrote: jerenkrantz2002/09/09 20:00:50 Modified:.CHANGES support htpasswd.c Log: Add ability to htpasswd (via -5) to produce non-obfuscated MD5 hashes. mod_auth_digest's passwords can not be obfuscated by the APR magic sequence (as we don't call apr_password_validate on them), therefore we need a tool to produce true MD5 hex hashes. Well, obviously, I needed to go back to mod_auth_digest school as htpasswd has nothing to do with mod_auth_digest which uses a completely different format. (I somehow forgot about htdigest.) But, I still think producing unobfuscated md5 hashes is a useful option, so I'll leave this commit in. -- justin Can it be parsed by mod_auth from an .htpasswd file? If not, please revert the commit. I agree with Bill. Please revert this commit. The problem is that mod_auth can't tell the difference between crypt() and MD5 without the string, which is why it was added in the first place. Also, MD5 isn't as portable as we had originally hoped. Some of the BSDs have modified their crypt() algorithm, which uses MD5, to use a slightly incompatible MD5. This means that if you try to take a crypt() password file to from a BSD machine, and move it to another box and try to make it use our MD5 algorithm, it won't work. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: El-Kabong -- HTML Parser
On Tue, 10 Sep 2002, Jim Jagielski wrote: Can we settle down? A donation of code was being offered, and there was discussion within the ASF about it, but the status of those discussions weren't being folded back to the donator. Before we veer off on yet another tangent, can we address the core issue? Should the ASF accept the code donation? I believe Greg has done a review of said code. This has been decided already. It was discussed in the APR PMC, and we decided to accept the code. We even decided where to put it. I personally disagree with the decision, but it was made by a majority of the voters, so I will stand by it. The code has been accepted by the APR PMC, and it is going into apr-util/html (I believe). Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: cvs commit: httpd-2.0/support htpasswd.c
This message is complete hand-waving. The point of htpasswd is to create password files for mod_auth. It doesn't create password files for use with other authentication schemes. More to the point, if anybody ever uses this option, it will FAIL with mod_auth. That violates the principle of least astonishment. If you don't document it, then it might as well not be there. Ryan On Tue, 10 Sep 2002, Justin Erenkrantz wrote: On Tue, Sep 10, 2002 at 11:57:08AM -0400, [EMAIL PROTECTED] wrote: I agree with Bill. Please revert this commit. The problem is that And, I think there is power in giving the user the choice to have correct MD5 hashes produced. Not every use of htpasswd is going to be fed into apr_password_validate(). If I were to write a new auth scheme or a CGI script where the client sends a correct MD5 hash of their password and I needed to verify that hash, this option would be essential. It isn't the default (heck, we could remove the option from the help or rot13 the option description), but even if it produces something not portable with apr_password_validate() but is a correct MD5 hash, I think we should allow users to produce it. -- justin -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: perchild under Solaris 8
On Tue, 10 Sep 2002, Jim Jagielski wrote: At 11:07 AM -0700 9/10/02, Aaron Bannert wrote: On Tue, Sep 10, 2002 at 01:07:30PM -0400, Jim Jagielski wrote: If '-D_XPG4_2 -D__EXTENSIONS__' are added to CPPFLAGS during the configure process, perchild will compile relatively cleanly under Solaris 8 and result in a binary that actually serves content!! Haven't yet playing with using the actual uid/gid aspects of perchild yet. I'm looking to see what affects, if any, adding these by default to APR and httpd will be... If anyone has some better experience with these, please let me know :) If that combo works, great, but I have a feeling it will break some other things. I have a combo somewhere around here that I am using on another module that allows solaris to expose the same file descriptor passing semantics, let me see if I can find it. I'm also concerned about breakage... Thing is, we're using msghdr for the recvmsg() calls. Yeah, I don't think Solaris uses the same structure/functions for passing fd's between processes. I had originally planned to use a Solaris box for the second port, but I don't have access to one yet. I keep looking on e-bay for a good x86 box though. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Tagged the tree
On Mon, 9 Sep 2002, Chris Taylor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Original Message - From: Aaron Bannert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 08, 2002 11:22 PM Subject: Re: Tagged the tree If there are enough people like Chris who want snapshot-like tarballs of development tags that we are making, I'd be happy to roll unofficial tarballs and stick them up on my site for a few days. +1 :) It would be very helpful for me, as I don't currently use CVS at all, and I'm not familiar with it. I can't say for sure, but I would think that by making tarballs of the tags available, it would encourage more people to get involved in testing each tag? After all, the more the merrier Um, the point is we don't want people testing the tags until they have been blessed as an alpha. Once it is an actual alpha release, there will be a tarball for testing. Te reason we don't want people testing (other than developers), is that the initial tag is a tool for the developers to make sure we have a viable tag. Remember, we used to create tarballs as soon as things were tagged, and then when we tried to push tags, we would create a new tarball. We shouldn't be pushing tags anymore. The reason we lay an initial tag (with the developers name, BTW), is so that if we have to change things, we can just lay another tag with their name and a new number. The goal for these releases, is to keep the barrier high, and ensure that developers have access to what we are going to release soon. Once the developers decide the tag is viable, the final tag is laid, and a tarball is created. This is when the barrier to entry is low, so that users can download and test. Then we vote on quality. The point is that the tags are cheap, and there should be more tags than tarballs. If we make it too easy to get the tags, then we won't be able to track what people have. By providing tarballs, we will be going back to what didn't work months ago. If you don't or can't use CVS, then you have to wait for the final tag and roll. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Is it time to split the APR/HTTPD releases ?
+1, as soon as both APR and APR-util have a release. Ryan On Sun, 8 Sep 2002, Ian Holsman wrote: APR now has version management. is it time to stop just tagging the HEAD of the apr/apr-util trees when we make a release and just use the offically released ones? ie.. we would bundle apr 0.9.1 with httpd 2.0.41, and possibly further on, not bundle apr in the httpd-tar ball, and just document/check the minimum version required? --Ian -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Tagged the tree
Generally, we do not create tarballs of tags, because the tags are meant to be used by developers before the release is rolled. The problem with tarballs, is that once they are created, they can be downloaded, and then it is very difficult to determine which version of the tarball a user has. By restricting things to just CVS tags, we can be sure that only developers or users who REALLY understad that they aren't getting a release get the code. Then, once it has been well tested, we can roll a tarball for general release. If you must have a tarball, your best bet is to use the snapshots. You won't always get the exact tag, but since there hasn't been any commits since the tag, you will for this release. Ryan On Sat, 7 Sep 2002, Chris Taylor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry if this is a stupid question, but is it possible to get this tag as a .tar.gz somewhere on apache.org? Downloading the tree via CVS is a slow task for my poor modem :) Chris Taylor - The guy with the PS2 WebServer Email: [EMAIL PROTECTED] - PGP: http://www.x-bb.org/chris.asc - - Original Message - From: Sander Striker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, September 07, 2002 4:12 PM Subject: Tagged the tree Hi, I tagged the tree today as STRIKER_2_0_41_PRE1. I'll do some testing this weekend myself and will retag for release after I get some positive feedback on this tag. Greg, could you bump daedalus to this tag next week to see how it holds? Sander -BEGIN PGP SIGNATURE- Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com iQA/AwUBPXqBgCqf8lmE2RZkEQIHNgCfVCo1h0GXVK86r/+iFR9/jg/s/dsAn3SF CwMY3thLcJGoN4Lkqm2ucE2U =OXrW -END PGP SIGNATURE- -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: compatibility with C++ modules
So I haven't really looked into how it works, but have you looked at mod_cplusplus? http://sourceforge.net/projects/modcplusplus/ Ryan On 6 Sep 2002, Jeff Trawick wrote: At about the same time recently that I was doing horrible, uncommittable hacks to the build to get Apache 2.0 to support C++ modules on HP-UX, somebody wrote a PR against Apache 1.3 pointing out the same issue I encountered: If httpd is to properly support C++ modules, it may need to be linked with something other than the C compiler front-end, depending on the compiler and the platform. Though we probably don't want to be in the business of pretending to support C++ modules in general, they certainly work with Apache on some platforms and we could at least make it simple for the user to specify the command to invoke to link httpd. This would default to the C compiler, but could be forced by the user to be g++ or aCC or whatever. ? --with-httpd-linker=g++ ? -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Releasing 2.0.41
On Fri, 6 Sep 2002, Dale Ghent wrote: On Fri, 6 Sep 2002, Greg Stein wrote: | On Fri, Sep 06, 2002 at 02:12:10PM -0500, William A. Rowe, Jr. wrote: | ... | There are a few other little bugs that I'd like to fix so that 2.0.41 | holds most folks for a month or few. I have no objection if you simply | want to use an interim tag so we consume only the bug fixes. But it's | possibly easier just to hold off till Monday, if you wouldn't mind. | | People usually have free time on the weekend, so the release is more easily | done then. | | You can always do a 2.0.42 next week if you'd like. argh, we have to remember... Apache 2.0 is GA, not beta! No, it is not. Apache 2.0.40 is GA. Apache 2.0 is a nonentity. 2.0.41 will start out as alpha, then be moved to beta, and finally to GA when and if we believe it is GA quality. Do NOT believe that just because 2.0.40 was GA, 2.0.41 will be too. We specifically said that wasn't true for 2.0. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: mod_mime on virtual requests?
On Wed, 4 Sep 2002, Justin Erenkrantz wrote: Someone recently brought up the fact that they couldn't add a PHP filter to a SVN-served repository via AddOutputFilter. I think this is due to the following issues: 1) type_checker is a run_first rather than run_all. Any reason why this isn't run_all? Switching it would allow mod_dav's hook and mod_mime's hook to run. I'm not sure what the reason is for run_first. 2) mod_mime only looks at the r-filename in find_ct. What would be nice is if there were a way for mod_mime to also look at path_info as well. That may or may not be wise in all situations but for the SVN case where the resource isn't file-backed and the rest of the file info is stored in path-info, that should happen. (Smells like a config directive.) Thoughts? And I wonder how the hypothetical ap_resource_t would play into this. -- justin It is run_first because each response can only have a single content-type, and the only reason to use that hook is to get the content-type. This is also a performance issue. If mod_mime finds the c-t, then mod_mime_magic shouldn't be run. What is mod_dav doing in the find_type hook? Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Filters question
On Wed, 4 Sep 2002, Graham Leggett wrote: Hi all, Is it possible to read brigades from two filter stacks simultaneously? Yes and no. The two filter stacks share no data at all, so it is perfectly safe to call ap_get_brigade on both filter stacks. However, we can't poll based on filter stacks (while it is technically possible, it is VERY difficult to do, and nobody has bothered to implement it yet). This means that you will really be calling one filter stack and then the other until you have all of the data. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: mod_mime on virtual requests?
On Wed, 4 Sep 2002, Justin Erenkrantz wrote: On Wed, Sep 04, 2002 at 09:45:47AM -0400, [EMAIL PROTECTED] wrote: It is run_first because each response can only have a single content-type, and the only reason to use that hook is to get the content-type. This is also a performance issue. If mod_mime finds the c-t, then mod_mime_magic shouldn't be run. Okay. What is mod_dav doing in the find_type hook? Actually, all it is doing is setting up the handler based on the method. It doesn't actually do anything with the content-type. What would be a better hook then? -- justin fixups, that is actually what the fixups phase is designed for. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: El-Kabong -- HTML Parser
There are currently two possible avenues. 1) The code goes into apr-util. 2) The code goes into a sandbox project. The APR option is faster, but there is some misgivings about whether it belongs in apr-util. The vote was done, and it seems to be accepted, but Greg was keeping tally, so I don't have the exact numbers about where it would go. I _think_, and I could be wrong, that it would be put in apr-util/html as a separate piece of apr-util. The second option will take a bit longer, because the sandbox project will need to be created first. I have tried to answer without letting any of my personal opinions show in the message, because that has caused some problems before. The real question now, is given those two options, which would you prefer. Not saying that your preference is the only factor i the decision, but it should be taken into account. There are also some people questioning why we are moving so quickly on this. The general feeling is that we should find the best fit before taking the code. If you are in a rush, then that would change things, but the understanding was just that you wanted to be kept in the loop about what is happening. Keep pinging, but the conversation is on-going, and very active, so there is little chance that it won't happen. It is really just a matter of time now. Ryan On Tue, 3 Sep 2002, Jon Travis wrote: Any word on this? (take 2) -- Jon On Mon, Aug 26, 2002 at 08:32:16PM -0700, Jon Travis wrote: Hi all... Jon Travis here... Covalent has written a pretty keen HTML parser (called el-kabong) which we'd like to offer to the ASF for inclusion in APR-util (or whichever other umbrella it fits under.) It's faster than anything I can find, provides a SAX stylee interface, uses APR for most of its operations (hash tables, etc.), and has a pretty nice testsuite. We use it in our code to re-write HTML on the fly. I would be the initial maintainer of the code. Please voice any interest, thanks. -- Jon -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: [VOTE] Location of aaa rewrite
On Tue, 3 Sep 2002, Justin Erenkrantz wrote: Please vote: [X] Check in aaa rewrite to 2.0. [ ] Check in aaa rewrite to 2.1. Ryan
Re: [VOTE] Location of aaa rewrite
On Tue, 3 Sep 2002, Chris Taylor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [ ] Check in aaa rewrite to 2.0. [X] Check in aaa rewrite to 2.1. My view is that it's important to keep 2.0 stable to attract new users, and breaking things all the time won't help :) Can I ask a stupid question? What have we actually broken since Apache 2.0 went GA? Binary compatibility? How many functions? How many of those were APR and not Apache? Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: [VOTE] Location of aaa rewrite
On Tue, 3 Sep 2002, Rasmus Lerdorf wrote: On Tue, 3 Sep 2002, Chris Taylor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [ ] Check in aaa rewrite to 2.0. [X] Check in aaa rewrite to 2.1. My view is that it's important to keep 2.0 stable to attract new users, and breaking things all the time won't help :) Can I ask a stupid question? What have we actually broken since Apache 2.0 went GA? Binary compatibility? How many functions? How many of those were APR and not Apache? Sure, both source and binary compatibility were broken numerous times. Check the PHP bug database for umpteen reports on each breakage. Okay, but how is that different from early releases of 1.3? Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: [VOTE] Location of aaa rewrite
On Tue, 3 Sep 2002, Rasmus Lerdorf wrote: On Tue, 3 Sep 2002, Rasmus Lerdorf wrote: On Tue, 3 Sep 2002, Chris Taylor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [ ] Check in aaa rewrite to 2.0. [X] Check in aaa rewrite to 2.1. My view is that it's important to keep 2.0 stable to attract new users, and breaking things all the time won't help :) Can I ask a stupid question? What have we actually broken since Apache 2.0 went GA? Binary compatibility? How many functions? How many of those were APR and not Apache? Sure, both source and binary compatibility were broken numerous times. Check the PHP bug database for umpteen reports on each breakage. Okay, but how is that different from early releases of 1.3? I don't know, but you asked the question which sort of implied that nothing had been broken. Okay, I was actually trying to imply that while we had broken stuff, we hadn't broken that much, and that some modules would actually still work (Except for the MMN). Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: authn/authz split
On Fri, 30 Aug 2002, William A. Rowe, Jr. wrote: At 01:48 AM 8/30/2002, Justin Erenkrantz wrote: Since no one had any feedback to the earlier posts about splitting the auth modules into authn/authz, I decided to just call it authn (old auth) and authz (what Dirk called access). http://www.apache.org/~jerenkrantz/new-aaa/aaa-authn-authz-split.tar.gz http://www.apache.org/~jerenkrantz/new-aaa/split/ (expanded) This is an extension over Dirk's aaa.tar.gz that he posted. It does *not* add the provider API. Notes: - apr_lib.h isn't where apr_password_validate is, it's apr_md5.h. - renamed mod_access* to mod_authz* - mod_access.c-mod_authz_default.c - mod_auth.c-mod_auth_basic.c - removed all internal prefixes on the config_recs - style cleanup - AuthUserFile will be a bit wonky until mod_auth_basic is refactored with provider support. My plan is to commit this tomorrow AM and then add in the provider support shortly thereafter. Any new files will be created from scratch rather than try to keep revision history. When we get done with this, the code won't look anything like what it was before. Any objections? Only one veto here. If it destabilizes the server, and we cannot react to new security incidents, that's not acceptable. Your next comment... I imagine auth may be a little wonky until this settles down, but once it settles down, we can ensure we're backwards-compat with the old aaa system. No one other than Aaron and myself seem interested in calling this 2.1, so we stay at 2.0 with this and potentially not having directive back-compat if it doesn't shake out. -- justin ...scares me. Now that it's GA, we should really be treating the 2.0 tree with the same respect and caution we use on the 1.3 tree. It's time for a 2.1-dev tree, if we want to be playing with new ideas, guys. If they test out clean and don't break compatibility [in any significant way] then they can be backported to 2.0. The 1.3 tree didn't become stable for many releases after the initial release. We definately didn't treat it with the respect and caution that we now use until well after the first alphas for 2.0 came out, which was years after the first 1.3 release. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: 2.1 repository?
[...] Look at all of the repositories we created that are still left around: apache-1.2 apache-1.3 apache-apr apache-nspr httpd-2.0 The apache-apr and apache-nspr repositories were fairly short-lived. I wasn't around when they were created, so perhaps the intention really was that they would be the 'next big thing.' Not sure about apache-apr, but IIRC apache-nspr was a combination of next big thing and sandbox for trying out this fancy styff. apache-nspr was Dean's attept at Apache 2.0, but it was corrupted by the NSPR license. Apache-apr was Manoj, Bill, and my first attempt at Apache 2.0 with APR. Both repositories were meant to become Apache 2.0, and both include MANY lessons learned while introducing threads into Apache. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: what's the hubbub? (was: Re: 2.0/2.1 split)
++1. Ryan On Fri, 30 Aug 2002, Jim Jagielski wrote: Ian Holsman wrote: what we need most is a stable tree for a couple of months not spliting out to a 2.1 tree ++1 -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: perchild on Darwin, hmmm
That is awesome! The code is REALLY crufty still, but it would be great to get more eys on it. Fair warning, it is REALLY fragile still. Happy hacking. :-) Ryan On Fri, 30 Aug 2002, Jim Jagielski wrote: Except for the poll.h header line, perchild compiled quite nicely on Darwin (Jaguar - 10.2). Also confirmed that it serves pages. Have *NOT* yet checked to see if the perchild specific goodies actually work yet. Next on the list :) Wish there were at least 5 hours more per day... ;) -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: El-Kabong -- HTML Parser
On Thu, 29 Aug 2002, Aaron Bannert wrote: Justin and I have both given our thumbs up. The question is now where to put the thing. A few people say APR, and few don't like that. A few say httpd, and a few don't like that. Bleh :-) I'm 100% comfy with the landing spot being in APR, as a compliment to the XML routines. +1 from me, I prefer APR actually. I am really uncomfortable with this going under the APR project. As things stand right now, it just doesn't fit with what we have stated our goals to be. If you want to change our stated goals, then go ahead and do it. Just committing code that doesn't fit with our goals isn't the way to do that. I will make one exception to that statement. If it lands inside of APR-util, under the XML directory, and it is made to work with the XML parser, I can accept that landing spot. As it fits in closer with our goals (I think). Jim, I can't decide if this is what you meant or not. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Going to 2.1? was Re: authentication rewrite
On Wed, 28 Aug 2002, Aaron Bannert wrote: On Wed, Aug 28, 2002 at 12:25:36PM -0700, Justin Erenkrantz wrote: branches in CVS are awful (perhaps not so with SVN though). I have only heard anecdotal evidence for this, but have actually used cvs branches on other large and very successful projects before. (*cough* PHP! *ahem*). I'd rather see a cvs branch than a whole new copy of the repository. We can wait until the 3.0 cycle to switch to SVN or start a new repository if we want. Not to mention our repository is httpd-2.0 - I don't think it makes sense to have a 2.1 in there. I'm not entirely sold on splitting off to a 2.1 yet, but I think we now have something where it is worth discussing it. -- justin I'd really like to see us start attacking smaller-grain problems and releasing those features more often, rather than lining up years and years of ooh me too and this too until we've got bugs coming out of our ears and nothing stable out the door for our users and testers. IMHO, a new auth framework is a *perfect* target for the next milestone, and it makes sense to call it 2.1. Any other opinions? Just the same one I've had all along. Fix it in 2.0. If it is a major config change, then we document it. We have made changes like this before. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Is anybody getting CVS commit messages?
I realized earlier today that I haven't been seeing commit messages. Is anybody getting these messages? Ryan -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Counting bytes_sent in core output_filter Re: [PATCH: Apache2.0] mod_log_config: input/output bytes
On Wed, 21 Aug 2002, Justin Erenkrantz wrote: On Wed, Aug 21, 2002 at 12:27:29AM -0700, Brian Pane wrote: The remaining problem is: how can we identify the request_rec from within core_output_filter()? Within that filter, f-r is NULL. I have some ideas for solving this by putting some metadata in the brigade to associate each EOS with the corresponding request. But is there a better solution that already exists for getting the request_rec? Actually, I thought it was already fixed, but you're right the connection filters don't yet have access to f-r. My thought would be when we create the request, we go through the filter stack and 'fixup' all filters in the output_filters chain to point at the right request_rec. Seems easy enough, but I'm not 100% sure that is clean enough. -- justin You don't really want to do that. The problem is that a connection can have multiple requests, which means that if you have a CONNECTION_FILTER with access to the request_rec, at some point, it will have invalid information about the current request (i.e. in between requests). The CONNECTION filters specifically do not have access to the request_rec, because they shouldn't be doing anything with the requests. To solve the original problem, just look for ap_check_pipeline_flush, and around that function (or in the core's log_transaction phase), just reset c-bytes_sent to 0. If you do it in the core's log_transaction phase, just make sure that the function is registered AP_HOOK_REALLY_LAST. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Adding apreq-2 to httpd-2.0
On 21 Aug 2002, Jeff Trawick wrote: Joe Schaefer [EMAIL PROTECTED] writes: The apreq developers would like to see apreq-2 [*] make its way into the apache 2 distribution. Here's why: Did you consider adding it to apr-util? (probably a dumb idea, but I'm interested in what other people think) I would think that this would be a better match for apr-serf. Ryan
Re: reading post data
Noah, I already answered your question through Jim Harter at Covalent. You cannot pass information from an input filter to the access checker, because the input filter runs during the handler phase, and the access_checker function runs long before that. You will need to do your access checking as a part of the input filter, and deny access within the access checker. As I told you, the HTTP_IN filter has a couple of examples of how to do this. While it is true that there isn't much information available for writing input filters, the best source currently available is the filters used in Apache itself. Ryan On Mon, 19 Aug 2002, Arliss, Noah wrote: Greetings, I have been working on a port to Apache 2.0 for some time now and have run into a road block that I would like to get feedback on. I need to run my module in the access_checker hook with the ability to read in Post data in a non-destructive manor. In apache 1.3 this was possible by hacking the request structure and putting the post data back for ap_get_client_block to read again. In Apache 2.0 this does not appear possible and I've been told to look at input filters. So I was wondering if it would be possible to somehow read data in my input filter and then pass it along to the access_checker phase? When are input filters executed? I'm hoping this will spark a discussion on the new apache 2.0 architecture here, since there is not a lot of information out there about filters yet and I'm sure others will benifit from this discussion. Thanks in advance for the help, Noah Arliss -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Question about command parsing in mod_ext_filter.
On Mon, 19 Aug 2002, William A. Rowe, Jr. wrote:
Don't we -already- have some argv parsing code in either proc.c or the mod_cgi
that could be used for this purpose??? Let's make that exported, accessible
code from apr itself.
We already have it, and it is exported from APR. Look in
strings/apr_cpystrn.c for apr_tokenize_to_argv.
Ryan
Bill
At 03:31 PM 8/19/2002, Paul J. Reder wrote:
After fixing the parse_cmd code to be able to handle escaped quotes (so that
it would process the full
/bin/awk '{print NR\: \ $N}'
instead of just
/bin/awk '{print NR\
(and then an error for the : \ $N}' part)) I ran into what appears to be
the next problem.
In parse_cmd it runs
/* parms now has the command-line to parse */
while (filter-numArgs 30
strlen(filter-args[filter-numArgs] =
ap_getword_white_nc(p, parms))) {
++filter-numArgs;
}
to break the command string into an args list of tokens. This code uses
*only* white
space as delimeters. Thus the input command string
/bin/awk '{print NR\: \ $N}'
gets broken into
/bin/awk
'{print
NR\:
\
$N}'
The question I have is, shouldn't this break down into either
/bin/awk
'{print NR\: \ $N}'
or
/bin/awk
'{print NR\
: \
$N}'
The above listed pieces end up as the args list passed on the apr_proc_create
call.
Thanks,
--
Paul J. Reder
---
The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure.
-- Albert Einstein
--
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
Re: [PATCH] UDP support
On Wed, 14 Aug 2002, Ian Holsman wrote: Ryan Bloom wrote: I don't believe that this should be incorporated into the core server. The core of Apache is an HTTP server, which means that it should only know how to listen on TCP sockets. The support is there however, for other socket types to be added to the server. For the UDP case, your protocol module should implement it's own listen directive, to allow people to add UDP sockets for your protocol module. Then, the protocol module can set the accept_function pointer in the listen_rec, which in this case should be set to unixd_udp_connect. Now, when the server returns from apr_poll, it will automatically call the correct function for the current socket type. I think we should get the patches that affect APR in the codebase as currently I don't think we can create a udp socket properly, and then we can discuss how http should listen on a UDP port. ryan.. are you happy with the changes to APR that this patch provides? Definately not in favor of the bucket changes. A UDP bucket should have it's own bucket type IMHO. As for the APR-proper changes, I need to look at them in more detail before I can give an educated opinion. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: daedalus is running httpd-2.0.pre40
I guess I wasn't clear. I have automation that creates a new conf/, then copies in httpd.conf* from the production conf/ with appropriate edits. So my conf/ directory exists, but doesn't contain mime.types (or several other files which aren't relevant on daedalus). make install runs after that. It used to copy in everything except the httpd.conf file, which worked perfectly for me. Now it doesn't copy *any* of the conf/* files because the directory exists. It would be better if we did this on a more granular level, i.e. check to see if the individual file exists in the target dir, then copy/don't copy as appropriate. If we had a customized mime.types, I wouldn't want it to get clobbered. I think the old code would have done that. The old code was blowing away everything in the directory on my machine. BTW, the current logic is precisely what 1.3 does, which is why I added it. If you have an existing conf/ directory, the assumption is that you have been using it to run Apache. The situation that you are trying to protect against is most likely not standard. My question, is why isn't your automation just copying the whole conf/ directory? Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: cvs commit: httpd-2.0 Makefile.in
On 19 Jul 2002 [EMAIL PROTECTED] wrote: gregames2002/07/19 08:11:58 Modified:.Makefile.in Log: Install mime.types and magic in conf/ if they don't already exist. This also re-enables existing logic to always install *-std.conf with substitutions made. These are then copied into *.conf (without the -std) if that file doesn't already exist. This is completely bogus IMO. You are working around a problem with your automation script in Apache. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: cvs commit: httpd-2.0 STATUS
On 17 Jul 2002 [EMAIL PROTECTED] wrote: trawick 2002/07/17 15:15:01 Modified:.STATUS Log: somebody please tell me I don't know how to read C code anymore (I guess the pool for an Apache socket will grow on every read/write operation that would block.) +* apr_poll() grows the pool (e.g., pchild or the thread's pool) on + each call... Apache MPMs don't have logic to work around this + issue. Well the goal was to optimize out that palloc over time, which just requires some profiling to find the most likely cases. Also, on platforms with alloca, we can allocate the pollset on the stack. All of this has been spelled out on the list, but I haven't had the time to do it yet. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
RE: PATH_INFO in A2?
On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: What is a dynamic page if not a PHP page? Like I said, Apache doesn't know if a file on disk is meant for PHP or not. The best way to fix this would be for mod_php to set the value if the filter is added for the request. I agree, it would be cool if Apache could set this correctly based on the filters that have been added for the request. Seems like there should be an API call where a filter can specify whether it is a dynamic one or not as opposed to specifically flipping the acceptpathinfo bit. We just added a new function for all input filters to allow this to be done (Justin referenced it in his reply). However, that function doesn't solve the problem, because there should be an ap_filter_is_dynamic(r) that hides the implementation details for all filters. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: cvs commit: httpd-2.0/server core.c
On 15 Jun 2002 [EMAIL PROTECTED] wrote: rbb 2002/06/14 22:49:06 Modified:.CHANGES server core.c Log: Make the default_handler catch all requests that aren't served by another handler. This also gets us to return a 404 if a directory is requested, there is no DirectoryIndex, and mod_autoindex isn't loaded. PR: 8045 Submitted by: Justin Erenkrantz Just to clarify. There was a comment in PR 8045 that returning 500 was better than 404 if a directory exists, but there is no index. I completely disagree. Users see a 500, and they get scared. IMO, a 404 means that we could not find a valid response, which is this case exactly. Plus, this matches what we did in 1.3, and users expect it. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: HEAD of a CGI script returning Content-Length?
On Wed, 12 Jun 2002, Justin Erenkrantz wrote: I noticed that when issuing a HEAD request on a CGI page (trying unsuccessfully to reproduce the showstopper), the Content-Length is not returned. RFC 2616 Section 9.4: The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. Obviously, there's wiggle-room here, but we could be nice and send the Content-Length. This does make the cost of a HEAD be equivalent to a GET (except for network I/O), but it ensures identical headers returned to the client. (Apache 1.3 doesn't send C-L either...) Thoughts? -- justin This has been discussed before, and every time it is, we state unequivicably that we need to return the C-L. Not because the spec says we need to, but because it is the correct thing to do. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: [PATCH] Switch DAV PUT to use brigades
+if (APR_BUCKET_IS_EOS(bucket)) {
+seen_eos = 1;
+break;
+}
+
+/* Ahem, what to do? */
+if (APR_BUCKET_IS_METADATA(bucket)) {
+continue;
+}
No need to test for this. You'll just get zero-length buckets. If an
important metadata bucket *does* get generated in the future, then we'd want
to be explicitly testing for and handling it (like what is being done for
the EOS bucket). Until then, we don't have to worry about them.
Um, I think the approach has been that you can't read from
metadata buckets. That they may give you data back or they may
not, but they certainly shouldn't be handled if you don't know
what to do with them. This comes out of what little I've seen
of the conversation with Cliff and Ryan. I may have it wrong,
but I think someone said at some point that metadata may indeed
respond to bucket_read with data, but that data shouldn't be
construed as part of the input stream. I'm thoroughly confused
at this point about what metadata buckets are.
No, currently o metadata bucket responds to a read with data, and the way
the metadata flag was implemented, it isn't possible for a metadata bucket
to have data.
I don't know the code well enough to know if this is implemented
correctly, but the rule follows:
All filters must make sure that all metadata buckets that they do not
handle are sent to the next filter. If a previous filter created an error
bucket, then that bucket must be sent to the next level.
Ryan
Re: Stripping Content-Length headers
On Sun, 5 May 2002, Justin Erenkrantz wrote: On Sun, May 05, 2002 at 06:26:53PM -0400, [EMAIL PROTECTED] wrote: The filter should remain regardless of whether there is a C-L, because we use that filter to determine exactly how much data was sent through the filter stack. That is useful information, and it doesn't hurt performance in any meaningful way (We are just looping through the brigade). However, the filter should be smart enought to leave the C-L alone, unless it is required. Okay, I guess. I do think it'd cause a performance hit though. But, I won't push it. I don't see the need for it though. However, I'm more concerned that we'll be buffering data on HTTP/1.0 requests that already have a C-L. This would be enormously expensive when we could have streamed the data to the network rather than holding on to it until EOS is seen. -- justin Take a closer look at the filter. We almost never actually buffer data in the C-L filter. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: Official Release: Apache 2.0.35 is now GA
Congrat's on the baby. :-) Ryan On Sun, 7 Apr 2002, Ian Holsman wrote: Greg Stein wrote: It's my pleasure to announce that the Apache Software Foundation's Apache HTTP Server, version 2.0.35, has now been released for General Availability. Gees guys.. you leave for a couple of days to have a baby and all hell breaks loose Congrats to all! --Ian The Apache 2.0 project has been in-the-works for nearly three years. It has been a long and sometimes arduous process to reach this point. Many, many people have contributed their time and effort to bring us to this point. The HTTPD Project signed off today on the 2.0.35 release, and recommends it for use on production websites. 2.0.35 is now considered our best release and should be used in preference to all older versions (including the 1.3 series). The Apache 2.0 series brings new features to the ASF's HTTP server: - higher performance over 1.3 - multiple operational models: threaded, hybrid processes/threads, and specific request processing for Windows, Netware, BeOS, and OS/2 - integrated SSL and WebDAV support - improved HTTP proxy support - I/O layering and filtering You can find more information, and download the server, from our website: http://httpd.apache.org/ On behalf of all the current and past developers, we'd like to thank all those involved with the project, and the millions(!) of users out there. The Apache HTTP server wouldn't enjoy its popularity without all of you! Sincerely, Greg Stein Director of the ASF -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
On 20 Mar 2002 [EMAIL PROTECTED] wrote:
wrowe 02/03/19 20:29:55
Modified:server/mpm/winnt mpm_winnt.c
Log:
When restarting [always graceful on Win32], we don't repeat pre_mpm
(Unix doesn't, we shouldn't either.) [Ryan Bloom]
-if ((parent_pid == my_pid) || one_process) {
+/* ### If non-graceful restarts are ever introduced - we need to rerun
+ * the pre_mpm hook on subsequent non-graceful restarts. But Win32
+ * has only graceful style restarts - and we need this hook to act
+ * the same on Win32 as on Unix.
+ */
+if (!restart ((parent_pid == my_pid) || one_process)) {
/* Set up the scoreboard. */
if (ap_run_pre_mpm(pconf, SB_SHARED) != OK) {
return 1;
While I agree with this patch, you also need to kill the cleanup on the
scoreboard, so that it isn't set to NULL when pconf is cleared. And, you
need to find some way to pass the scoreboard back to the child process
because you are about to start a new one.
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
