Re: Showstoppers on 2.0.41

[Peter Van Biesen]

Hi,

I finally got the time to compile 2.0.43; the problem is solved !

Thanks to all those who searched an found memory leaks !!

Peter.

Peter Van Biesen wrote:

>There was still a memory leak when downloading large files, but only
>when proxy chaining. I haven't tested the latest release yet as my boss
>wants me to do other things, but I'll do it as soon as I can. Anyway,
>this problem, if it were not to be fixed, should not stop the release of
>2.0.41, as it only occurs with files larger than 70 Mb and when
>proxychaining.
>
>Peter.
>
>Brian Pane wrote:
>  
>
>>On Fri, 2002-09-13 at 15:21, William A. Rowe, Jr. wrote:
>>
>>
>>>I see two blocking issues, based on STRIKER_2_0_41_PRE2
>>>
>>>One is an absolute must... gotta push back apr-util/include/apu.hw
>>>to rev 1.10 or we don't build on win32.
>>>
>>>The other is a nice-to-have with "no excuses"(R)...  reverse the -c flag
>>>for the htpasswd (and htdigest et al?) support utilities.  How many
>>>versions in a row can we release broken versions of such a simple utility?
>>>
>>>Bill
>>>  
>>>
>>A couple of others:
>>  * 2.0.41 should include the fix for disabling native atomics
>>on Sparcs (apr/include/apr_atomic.h 1.36, which is one rev
>>newer than the STRIKER_2_0_41_PRE2 tag).
>>  * If anybody has a memory leak test case that still appears
>>under _PRE2, please speak up soon!
>>
>>-Brian
>>
>>
>
>  
>

Re: Problem with cache+proxy and multiple brigade

[Graham Leggett]

Matthieu Estrade wrote:

> I found a problem with mod_cache and mod_proxy...
> 
> when cache is storing the data + headers in memory, it doesn't care 
> about Transfert-Encoding...

AFAIK proxy should always dechunck any chunked data it receives before 
passing it up the stack. The caching stuff should never see chunked data.

If cache does, it could be because someone is putting the cache filter 
in the wrong place in the stack, ie before the dechunk filter.

> +/* Delete Transfer-Encoding if present, coming from reverse proxy */
> +
> +if (apr_table_get(r->headers_out,"Transfer-Encoding")){
> + apr_table_unset(r->headers_out,"Transfer-Encoding");
> +}
> + 

Just arbly deleting the transfer encoding will definitely not work. You 
need to make sure the content is dechunked as well. Only the dechunk 
filter should remove the transfer encoding header.

Regards,
Graham
-- 
-
[EMAIL PROTECTED]"There's a moon
over Bourbon Street
tonight..."

Re: cvs commit: httpd-2.0/server/mpm/winnt child.c

[Sebastian Bergmann]

[EMAIL PROTECTED] wrote:
> wrowe   2002/10/13 20:13:20
>
>   Modified:server/mpm/winnt child.c
>   Log:
> Handle WSA_IO_PENDING as well.

  My VisualC++ 6 (with MS Platform SDK May 2002) chokes on lines 528 and
  529.

  There seem to be two ")"s missing, as well as a boolean operator (XX)
  to connect the two terms:

528: else if ((rv != APR_FROM_OS_ERROR(ERROR_IO_PENDING)) XX
529:  (rv != APR_FROM_OS_ERROR(WSA_IO_PENDING))) {

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

[PATCH]: Counting of I/O V2, with symmetrical approach

[Bojan Smojver]

I'm aware that some people might not like this due to the fact that it's
inserting yet another default filter, but here it is, just for completeness.

Bojan

diff -u --recursive --new-file httpd-2.0-vanilla/include/ap_mmn.h 
httpd-2.0/include/ap_mmn.h
--- httpd-2.0-vanilla/include/ap_mmn.h  Wed Sep  4 14:12:20 2002
+++ httpd-2.0/include/ap_mmn.h  Mon Oct 14 11:47:46 2002
@@ -111,12 +111,13 @@
  * 20020625 (2.0.40-dev) Changed conn_rec->keepalive to an enumeration
  * 20020628 (2.0.40-dev) Added filter_init to filter registration functions
  * 20020903 (2.0.41-dev) APR's error constants changed
+ * 20021014 (2.0.44-dev) conn_rec gets bytes_in and bytes_out fields
  */
 
 #define MODULE_MAGIC_COOKIE 0x41503230UL /* "AP20" */
 
 #ifndef MODULE_MAGIC_NUMBER_MAJOR
-#define MODULE_MAGIC_NUMBER_MAJOR 20020903
+#define MODULE_MAGIC_NUMBER_MAJOR 20021014
 #endif
 #define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */
 
diff -u --recursive --new-file httpd-2.0-vanilla/include/httpd.h 
httpd-2.0/include/httpd.h
--- httpd-2.0-vanilla/include/httpd.h   Sat Oct 12 02:12:28 2002
+++ httpd-2.0/include/httpd.h   Mon Oct 14 11:47:46 2002
@@ -1018,6 +1018,10 @@
 void *sbh;
 /** The bucket allocator to use for all bucket/brigade creations */
 struct apr_bucket_alloc_t *bucket_alloc;
+/** Input bytes on this connection */
+apr_off_t bytes_in;
+/** Output bytes on this connection */
+apr_off_t bytes_out;
 };
 
 /* Per-vhost config... */
diff -u --recursive --new-file httpd-2.0-vanilla/modules/loggers/mod_logio.c 
httpd-2.0/modules/loggers/mod_logio.c
--- httpd-2.0-vanilla/modules/loggers/mod_logio.c   Sat Sep 28 14:18:35 2002
+++ httpd-2.0/modules/loggers/mod_logio.c   Mon Oct 14 14:56:09 2002
@@ -84,35 +84,18 @@
 
 module AP_MODULE_DECLARE_DATA logio_module;
 
-static const char logio_filter_name[] = "LOG_INPUT_OUTPUT";
-
-/*
- * Logging of input and output config...
- */
-
-typedef struct logio_config_t {
-apr_off_t bytes_in;
-apr_off_t bytes_out;
-} logio_config_t;
-
 /*
  * Format items...
  */
 
 static const char *log_bytes_in(request_rec *r, char *a)
 {
-logio_config_t *cf = ap_get_module_config(r->connection->conn_config,
-  &logio_module);
-
-return apr_off_t_toa(r->pool, cf->bytes_in);
+return apr_off_t_toa(r->pool, r->connection->bytes_in);
 }
 
 static const char *log_bytes_out(request_rec *r, char *a)
 {
-logio_config_t *cf = ap_get_module_config(r->connection->conn_config,
-  &logio_module);
-
-return apr_off_t_toa(r->pool, cf->bytes_out);
+return apr_off_t_toa(r->pool, r->connection->bytes_out);
 }
 
 /*
@@ -121,71 +104,15 @@
 
 static int logio_transaction(request_rec *r)
 {
-logio_config_t *cf = ap_get_module_config(r->connection->conn_config,
-  &logio_module);
-
-cf->bytes_in = cf->bytes_out = 0;
+r->connection->bytes_in = r->connection->bytes_out = 0;
 
 return OK;
 }
 
 /*
- * Logging of input and output filters...
- */
-
-static apr_status_t logio_out_filter(ap_filter_t *f,
- apr_bucket_brigade *bb) {
-apr_off_t length;
-logio_config_t *cf = ap_get_module_config(f->c->conn_config, &logio_module);
-
-if (!cf) { /* Create config */
-cf = apr_pcalloc(f->c->pool, sizeof(*cf));
-ap_set_module_config(f->c->conn_config, &logio_module, cf);
-}
-
-apr_brigade_length (bb, 0, &length);
-
-if (length > 0)
-cf->bytes_out += length;
-
-return ap_pass_brigade(f->next, bb);
-}
-
-static apr_status_t logio_in_filter(ap_filter_t *f,
-apr_bucket_brigade *bb,
-ap_input_mode_t mode,
-apr_read_type_e block,
-apr_off_t readbytes) {
-apr_off_t length;
-apr_status_t status;
-logio_config_t *cf = ap_get_module_config(f->c->conn_config, &logio_module);
-
-status = ap_get_brigade(f->next, bb, mode, block, readbytes);
-
-if (!cf) { /* Create config */
-cf = apr_pcalloc(f->c->pool, sizeof(*cf));
-ap_set_module_config(f->c->conn_config, &logio_module, cf);
-}
-
-apr_brigade_length (bb, 0, &length);
-
-if (length > 0)
-cf->bytes_in += length;
-
-return status;
-}
-
-/*
  * The hooks...
  */
 
-static int logio_pre_conn(conn_rec *c) {
-ap_add_input_filter(logio_filter_name, NULL, NULL, c);
-ap_add_output_filter(logio_filter_name, NULL, NULL, c);
-
-return OK;
-}
-
 static int logio_pre_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp)
 {
 static APR_OPTIONAL_FN_TYPE(ap_register_log_handler) *log_pfn_register;
@@ -204,14 +131,8 @@
 {
 static const char *pre[] = { "mod_log_config.c", NULL };
 
-ap_hook_pre_connection(logio_pre_conn, NULL, NULL, APR_HOOK_MIDDLE);
 ap_hook_pre_config(logio_pre_

[PATCH]: Counting of I/O, complete thingy

[Bojan Smojver]

I'm not sure if I missed a spot somewhere in core_output_filter, hopefully not.

After playing a bit with core_input_filter and not getting what I wanted, I kept
the original input filter in mod_logio (which was working fine to the best of my
knowledge). However, with the introduction of two new fields in conn_rec, things
should be even quicker than before. In order to make things symmetrical, the
actual filter could go into core.c. Otherwise, if mod_logio isn't compiled in,
the input numbers will always be zero, so other modules won't be able to use
them (which might be a good thing, not sure here).

My tests show that this works OK. I've been testing with 80 MB files and I'd get
different results (i.e. the numbers reported by %O) depending on when I pressed
Stop in my browser.

Unfortunately, this kind of approach does require the infamous MMN bump :-(
Any input is welcome...

Bojan

diff -u --recursive --new-file httpd-2.0-vanilla/include/ap_mmn.h 
httpd-2.0/include/ap_mmn.h
--- httpd-2.0-vanilla/include/ap_mmn.h  Wed Sep  4 14:12:20 2002
+++ httpd-2.0/include/ap_mmn.h  Mon Oct 14 11:47:46 2002
@@ -111,12 +111,13 @@
  * 20020625 (2.0.40-dev) Changed conn_rec->keepalive to an enumeration
  * 20020628 (2.0.40-dev) Added filter_init to filter registration functions
  * 20020903 (2.0.41-dev) APR's error constants changed
+ * 20021014 (2.0.44-dev) conn_rec gets bytes_in and bytes_out fields
  */
 
 #define MODULE_MAGIC_COOKIE 0x41503230UL /* "AP20" */
 
 #ifndef MODULE_MAGIC_NUMBER_MAJOR
-#define MODULE_MAGIC_NUMBER_MAJOR 20020903
+#define MODULE_MAGIC_NUMBER_MAJOR 20021014
 #endif
 #define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */
 
diff -u --recursive --new-file httpd-2.0-vanilla/include/httpd.h 
httpd-2.0/include/httpd.h
--- httpd-2.0-vanilla/include/httpd.h   Sat Oct 12 02:12:28 2002
+++ httpd-2.0/include/httpd.h   Mon Oct 14 11:47:46 2002
@@ -1018,6 +1018,10 @@
 void *sbh;
 /** The bucket allocator to use for all bucket/brigade creations */
 struct apr_bucket_alloc_t *bucket_alloc;
+/** Input bytes on this connection */
+apr_off_t bytes_in;
+/** Output bytes on this connection */
+apr_off_t bytes_out;
 };
 
 /* Per-vhost config... */
diff -u --recursive --new-file httpd-2.0-vanilla/modules/loggers/mod_logio.c 
httpd-2.0/modules/loggers/mod_logio.c
--- httpd-2.0-vanilla/modules/loggers/mod_logio.c   Sat Sep 28 14:18:35 2002
+++ httpd-2.0/modules/loggers/mod_logio.c   Mon Oct 14 14:10:07 2002
@@ -84,16 +84,7 @@
 
 module AP_MODULE_DECLARE_DATA logio_module;
 
-static const char logio_filter_name[] = "LOG_INPUT_OUTPUT";
-
-/*
- * Logging of input and output config...
- */
-
-typedef struct logio_config_t {
-apr_off_t bytes_in;
-apr_off_t bytes_out;
-} logio_config_t;
+static const char logio_filter_name[] = "COUNT_INPUT_BYTES";
 
 /*
  * Format items...
@@ -101,18 +92,12 @@
 
 static const char *log_bytes_in(request_rec *r, char *a)
 {
-logio_config_t *cf = ap_get_module_config(r->connection->conn_config,
-  &logio_module);
-
-return apr_off_t_toa(r->pool, cf->bytes_in);
+return apr_off_t_toa(r->pool, r->connection->bytes_in);
 }
 
 static const char *log_bytes_out(request_rec *r, char *a)
 {
-logio_config_t *cf = ap_get_module_config(r->connection->conn_config,
-  &logio_module);
-
-return apr_off_t_toa(r->pool, cf->bytes_out);
+return apr_off_t_toa(r->pool, r->connection->bytes_out);
 }
 
 /*
@@ -121,36 +106,15 @@
 
 static int logio_transaction(request_rec *r)
 {
-logio_config_t *cf = ap_get_module_config(r->connection->conn_config,
-  &logio_module);
-
-cf->bytes_in = cf->bytes_out = 0;
+r->connection->bytes_in = r->connection->bytes_out = 0;
 
 return OK;
 }
 
 /*
- * Logging of input and output filters...
+ * Logging of input filter...
  */
 
-static apr_status_t logio_out_filter(ap_filter_t *f,
- apr_bucket_brigade *bb) {
-apr_off_t length;
-logio_config_t *cf = ap_get_module_config(f->c->conn_config, &logio_module);
-
-if (!cf) { /* Create config */
-cf = apr_pcalloc(f->c->pool, sizeof(*cf));
-ap_set_module_config(f->c->conn_config, &logio_module, cf);
-}
-
-apr_brigade_length (bb, 0, &length);
-
-if (length > 0)
-cf->bytes_out += length;
-
-return ap_pass_brigade(f->next, bb);
-}
-
 static apr_status_t logio_in_filter(ap_filter_t *f,
 apr_bucket_brigade *bb,
 ap_input_mode_t mode,
@@ -158,19 +122,13 @@
 apr_off_t readbytes) {
 apr_off_t length;
 apr_status_t status;
-logio_config_t *cf = ap_get_module_config(f->c->conn_config, &logio_module);
 
 status = ap_get_brigade(f->next, bb, mode, block, readbytes);
 
-if (!cf) { /* Create config */
-cf = a

Re: Auth: Start the httpd-2.1 branch finally?

[rbb]

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: Auth: Start the httpd-2.1 branch finally?

[William A. Rowe, Jr.]

At 08:36 PM 10/13/2002, Joshua Slive wrote:
>André Malo wrote:
>>I've tried to find a solution. It's certainly not complete, but a first
>>suggestion. I simply fetched the old module docs from the Attic, named
>>them "obs_*" and modified the xslt a little bit. As proposed by
>>Joshua they got the status "Obsolete" and also a large warning on top of
>>the page. The modules are listed on module index
>>
>
>+1.  That is about what I had in mind.  The  at the top could be improved a 
>little.  Something along the lines, "This module was replaced in version 2.0.44 and 
>greater by mod_... (and mod_...).
>For more information, see ..."
>
>>I think we need a document that explains exactly the changes and the new
>>provider mechanism, so we may set links from both (pre and post) module
>>docs. 
>
>Absolutely essential before the next release.  If it is simple it can go in 
>upgrading.html.  If it is complicated, it should get a separate doc and be linked 
>from there.
>
>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.

On that same thought... mod_auth_basic is equally obtuse.  Renaming
it back to mod_auth doesn't seem like a stretch (if you consider that the
simplest auth is basic.)  Of course, we don't lose the ability to leave
mod_auth unloaded and simply load mod_auth_digest.

Obviously, loading mod_authn_file, mod_authn_default, mod_authz_file,
mod_authz_default, mod_authz_groupfile, mod_authz_host, and
mod_authz_user are going to be required to retain behavior that folks
are expecting.  But at least the renames could go.

BTW André, nice start.  I'd call out "mod_auth (prior to 2.0.44)"
as it's index entry, if we keep the mod_auth_basic concept.  Likewise
for mod_access.

Bill

Bill

Re: Auth: Start the httpd-2.1 branch finally?

[Justin Erenkrantz]

--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?

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

[PATCH]: conn_rec: new fields, bytes_in and bytes_out

[Bojan Smojver]

The fields would be used to correctly record the number of input and output
bytes ACTUALLY read/written per connection. This would not be the same as
r->bytes_sent, due to headers and encryption, but it could be used later on to
log this information using %I and %O. At this point I'm unsure how to best solve
the r->bytes_sent problem (actually, I'm not 100% sure of r->bytes_sent
semantics as well), but this would at least fix some of the inaccuracies of the
current code and would provide users with very accurate numbers. It would also
be faster then current mod_logio filter approach.

If this gets accepted, I would then write modifications to core_input_filter,
core_output_filter and friends that would use these fields to count the bytes
received and sent properly. I would also modify mod_logio to use these fields
instead of it's own little structure. Optionally, I could fold mod_logio back
into mod_log_config, given this would be part of core functionality.

Bojan

PS. In the spirit of 2.0 v. 2.1 thread, if you want me to write the whole thing
up front, just let me know. I have no problem doing one bigger patch making all
the necessary changes at once.


conn_rec-in-out.patch
Description: Binary data

Re: Auth: Start the httpd-2.1 branch finally?

[Joshua Slive]

André Malo wrote:
> I've tried to find a solution. It's certainly not complete, but a first
> suggestion. I simply fetched the old module docs from the Attic, named
> them "obs_*" and modified the xslt a little bit. As proposed by
> Joshua they got the status "Obsolete" and also a large warning on top of
> the page. The modules are listed on module index
> 
> 

+1.  That is about what I had in mind.  The  at the top could be 
improved a little.  Something along the lines, "This module was replaced 
in version 2.0.44 and greater by mod_... (and mod_...).
For more information, see ..."

> 
> I think we need a document that explains exactly the changes and the new
> provider mechanism, so we may set links from both (pre and post) module
> docs. 

Absolutely essential before the next release.  If it is simple it can go 
in upgrading.html.  If it is complicated, it should get a separate doc 
and be linked from there.

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.

Joshua.

Re: Auth: Start the httpd-2.1 branch finally?

[André Malo]

* rbb wrote:

> On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote:
>> 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.

I've tried to find a solution. It's certainly not complete, but a first
suggestion. I simply fetched the old module docs from the Attic, named
them "obs_*" and modified the xslt a little bit. As proposed by
Joshua they got the status "Obsolete" and also a large warning on top of
the page. The modules are listed on module index



below all other modules and on the sitemap the same way:



However, the directives don't appear in directive indexes (because of
status='obsolete'). 

The whole patch can be found here:


I think we need a document that explains exactly the changes and the new
provider mechanism, so we may set links from both (pre and post) module
docs. 

Comments, further suggestions and flames are welcome.

nd
-- 
"Die Untergeschosse der Sempergalerie bleiben währenddessen aus
 statistischen Gründen geflutet." -- Spiegel Online

Re: Auth: Start the httpd-2.1 branch finally?

[William A. Rowe, Jr.]

At 05:33 PM 10/13/2002, Justin Erenkrantz wrote:
>--On Sunday, October 13, 2002 5:15 PM -0500 "William A. Rowe, Jr." <[EMAIL PROTECTED]> 
>wrote:
>
>>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.
>
>Ten binding votes were cast for this change with the understanding that it might 
>break backwards compatibility.  Only one binding vote was cast for the aaa rewrite 
>being in 2.1.

First, anyone can vote.  Only committers have vetos.

2.0: rbb, brianp, dreid, gstein, jim, rederpj, striker, trawick,
 ianh, gs, bnicholes
2.1: dpejesh, chris, aaron, hb

Note that neither Bill voted, apparently that would be six votes for 2.1.
But you are ignoring that striker has already implicitly voted against
2.0 by releasing 2.0.42 sans auth changes.  And I released 2.0.43
sans auth changes.

I said, I'm not vetoing without three strong -1's on this code.  I'm not
certain Bill's concerns are addressed.  I'm not certain Aaron's are
addressed.  After I get strong -1's, I'll personally veto.  Then we can
resume the 2.1 branch discussion as a separate point.

And I would like to see what rbb creates for documentation.  That
will affect my -1, at least.

>Personally, I think the consensus of the group was clear.  -- justin

This was the very definition of a non-consensus decision.

Main Entry: con·sen·sus 

1 a : general agreement : UNANIMITY  b : the judgment arrived at by most of 
those concerned 
© 2002 by Merriam-Webster, Incorporated

Re: Auth: Start the httpd-2.1 branch finally?

[Jim Jagielski]

William A. Rowe, Jr. wrote:
> 
> 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.
> 
> Branch 2.1 now?  Only if we want to release the auth changes with all of
> the upgrade issues of deprecating several released module.  It doesn't matter 
> that "only the names have changed", this is called deprecating a module,
> and it shouldn't happen within a GA release cycle on the same minor version.
> 

But we've done it before... IIRC the referer logging module for example.

I 100% appreciate your POV that a bump to 2.1 makes the change
even more "substantial" and cleaner. However, I think the group
consensus is that the time to branch off a 2.1 isn't quite ready
yet.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

Re: Auth: Start the httpd-2.1 branch finally?

[William A. Rowe, Jr.]

At 05:35 PM 10/13/2002, [EMAIL PROTECTED] wrote:
>On Sun, 13 Oct 2002, William A. Rowe, Jr. wrote:
>> 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.

And not one member of that majority has been willing to tackle the issue
of supporting 2.0 with this change going into this revision.

Sure it was discussed, voted upon even.  Until we look squarely at the consequences of 
this transition, we were voting on the spirit of the changes.
For example, the rename from mod_access to mod_authn_host mid-reversion
is gratuitous.  It just made more sense.  I'm very concerned that we won't
have the flexibility to rearrange this further, by trying to prevent user
confusion.  Of course, the few loud voices clearly aren't concerned about
the confusion factor in the first place, so I suppose such concerns won't halt 
progress going forward.

>> >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.

Don't be too stubborn to surrender after you start, though, if it isn't
going the way you would like  :-)

Without any sarcasm, thank you for attacking this, and I'm looking forward
to reading them.  

Bill

HTTP EnableSendfile directive and new mechanics

[William A. Rowe, Jr.]

To both lists, since this patch affects APR and sendfile.

The attached patch introduces the EnableSendfile directive for httpd.  Jeff and
I have seen several cases, including NFS shares and so forth, that are not
compatible with apr_sendfile.  It works similarly to EnableMMAP but the
differences are worth discussing.  {This is why I'm posting and not yet ready
to commit.}

The EnableMMAP worked by adding a flag to the bucket.  However, it seems
very silly to do so when what we really want to toggle is the file.

We also have an issue on Win32, we weren't using the correct open file semantics.
This may have had something to do with BSoD (kernel panic) using some socket
drivers on Win32.  Opening for TransmitFile should be done with sequential
optimizations and I believe it must be opened overlapped (that XTHREAD flag.)

But the XTHREAD flag means more than just sendfile - it means multiple threads
will need atomic seek-read/write operations on all platforms.  That wasn't the
right flag to play with across the board.

So this patch proposes an APR_OPEN_FOR_SENDFILE bit, where that bit
has little impact on any platform but Win32.

BUT - it does act as a sentinal that we can sendfile the flag.  This allows us, at
the apr_file_t granularity, to choose to sendfile or not.  It also can get rid of some
nasty side effects like Win9x which can't sendfile.  We decide this at runtime, so
we will simply unset that flag if requested.

Finally, we already have the semantics to recover the flags value from an apr_file_t,
giving the HTTP core output filter the final word to sendfile or not to sendfile.

Comments welcome, I'll commit midweek if nobody hollers.

Bill


Index: include/http_core.h
===
RCS file: /home/cvs/httpd-2.0/include/http_core.h,v
retrieving revision 1.68
diff -u -r1.68 http_core.h
--- include/http_core.h 3 Oct 2002 00:16:47 -   1.68
+++ include/http_core.h 13 Oct 2002 21:42:58 -
@@ -532,7 +532,12 @@
 #define ENABLE_MMAP_OFF(0)
 #define ENABLE_MMAP_ON (1)
 #define ENABLE_MMAP_UNSET  (2)
-int enable_mmap;  /* whether files in this dir can be mmap'ed */
+unsigned int enable_mmap : 2;  /* whether files in this dir can be mmap'ed */
+
+#define ENABLE_SENDFILE_OFF(0)
+#define ENABLE_SENDFILE_ON (1)
+#define ENABLE_SENDFILE_UNSET  (2)
+unsigned int enable_sendfile : 2;  /* files in this dir can be mmap'ed */
 
 } core_dir_config;
 
Index: server/core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.211
diff -u -r1.211 core.c
--- server/core.c   13 Oct 2002 18:22:55 -  1.211
+++ server/core.c   13 Oct 2002 21:43:08 -
@@ -181,6 +181,7 @@
 conf->etag_remove = ETAG_UNSET;
 
 conf->enable_mmap = ENABLE_MMAP_UNSET;
+conf->enable_sendfile = ENABLE_SENDFILE_UNSET;
 
 return (void *)conf;
 }
@@ -447,6 +448,10 @@
 conf->enable_mmap = new->enable_mmap;
 }
 
+if (new->enable_sendfile != ENABLE_SENDFILE_UNSET) {
+conf->enable_sendfile = new->enable_sendfile;
+}
+
 return (void*)conf;
 }
 
@@ -1458,6 +1463,29 @@
 return NULL;
 }
 
+static const char *set_enable_sendfile(cmd_parms *cmd, void *d_,
+   const char *arg)
+{
+core_dir_config *d = d_;
+const char *err = ap_check_cmd_context(cmd, NOT_IN_LIMIT);
+
+if (err != NULL) {
+return err;
+}
+
+if (strcasecmp(arg, "on") == 0) {
+d->enable_sendfile = ENABLE_SENDFILE_ON;
+}
+else if (strcasecmp(arg, "off") == 0) {
+d->enable_sendfile = ENABLE_SENDFILE_OFF;
+}
+else {
+return "parameter must be 'on' or 'off'";
+}
+
+return NULL;
+}
+
 static const char *satisfy(cmd_parms *cmd, void *c_, const char *arg)
 {
 core_dir_config *c = c_;
@@ -2936,6 +2964,8 @@
   "Specify components used to construct a file's ETag"),
 AP_INIT_TAKE1("EnableMMAP", set_enable_mmap, NULL, OR_FILEINFO,
   "Controls whether memory-mapping may be used to read files"),
+AP_INIT_TAKE1("EnableSendfile", set_enable_sendfile, NULL, OR_FILEINFO,
+  "Controls whether sendfile may be used to transmit files"),
 
 /* Old server config file commands */
 
@@ -3283,8 +3313,13 @@
 }
 }
 
-if ((status = apr_file_open(&fd, r->filename, APR_READ | APR_BINARY, 0,
-r->pool)) != APR_SUCCESS) {
+
+if ((status = apr_file_open(&fd, r->filename, APR_READ | APR_BINARY
+#if APR_HAS_SENDFILE
+ | ((d->enable_sendfile == ENABLE_SENDFILE_OFF) 
+? 0 : APR_OPEN_FOR_SENDFILE)
+#endif
+, 0, r->pool)) != APR_SUCCESS) {
 ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r,
   "file permissions deny server access: %s", r->filename);
 return HTTP_FORBI

Re: Auth: Start the httpd-2.1 branch finally?

[rbb]

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?

[Justin Erenkrantz]

--On Saturday, October 12, 2002 1:17 PM -0700 Aaron Bannert 
<[EMAIL PROTECTED]> wrote:

> That seems like a one-way street to me. How come it's ok to work on
> the auth changes in 2.0 but it's not ok for others?

As Sander pointed out, the aaa changes were made first, then we voted 
on where they went.  So, no, I don't see a double standard.  -- justin

Re: Auth: Start the httpd-2.1 branch finally?

[Justin Erenkrantz]

--On Sunday, October 13, 2002 5:15 PM -0500 "William A. Rowe, Jr." 
<[EMAIL PROTECTED]> wrote:

> 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.

Ten binding votes were cast for this change with the understanding 
that it might break backwards compatibility.  Only one binding vote 
was cast for the aaa rewrite being in 2.1.

Personally, I think the consensus of the group was clear.  -- justin

Re: Auth: Start the httpd-2.1 branch finally?

[William A. Rowe, Jr.]

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.

>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.

>You are so focused on getting a 2.1 branch, that you are ignoring any other 
>solutions to the problem that you have raised.

I'm focused on persuading the HTTP group to quit messing up administrators 
and third party module authors.  It matters very little to me if we make forward
progress if we continue to treat the httpd-2.0 tree as a sandbox and alienate
our third party authors and adopters.

Branch 2.1 now?  Only if we want to release the auth changes with all of
the upgrade issues of deprecating several released module.  It doesn't matter 
that "only the names have changed", this is called deprecating a module,
and it shouldn't happen within a GA release cycle on the same minor version.

Bill

Re: Auth: Start the httpd-2.1 branch finally?

[Justin Erenkrantz]

--On Sunday, October 13, 2002 4:57 PM -0500 "William A. Rowe, Jr." 
<[EMAIL PROTECTED]> wrote:

> I challenge you to do so; document both the old and the new so that
>
>http://httpd.apache.org/docs-2.0/
>
> clearly documents both the pre-new-auth and post-new-auth.  I'm
> presuming it can't be done -well-, because it hasn't been done.  I
> grappled with the idea this weekend and surrendered.  That's when I
> revisited my original vote to  implement this in 2.1 ... like
> FirstBill offered, I too should have hollered louder. But no users
> have been harmed, and the code will go in (to 2.0 or 2.1).

I'm sorry, but I don't see a need to have the documentation refer to 
historical (or deprecated) modules.  If you have an older version, 
the docs included in that release tarball are the definitive version. 
IMHO, the docs on the website should only refer to the currently 
released version.  -- justin

Re: Auth: Start the httpd-2.1 branch finally?

[Jim Jagielski]

At 1:05 PM -0500 10/13/02, William A. Rowe, Jr. wrote:
>
>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.
>

In a nutshell, here are my thoughts: Creating a 2.1 branch will
sacrifice 2.0. I really feel that if 2.1 is started, 2.0 will basically
stay the exact same way it is right now. And although 2.0 *is* production
ready, there is still a lot more that could be done with it, to make
it better.

Consider what happened with 2.0 and 1.3: When 2.0 started "in earnest"
development on 1.3 was frowned upon. "No new features" and the
like. 2.0 was the "cool project" to work on, and 1.3 was considered
"old stuff". This only succeeded because (1) 1.3 was very, very robust.
It was solid and had been worked on and tuned enough that it could
be somewhat "left alone" and (2) that some of us decided to make
sure that 1.3 was still a living a breathing project, despite
some developer inklings that "you should really be working on 2.0."

2.0 is not, IMO, at a stage where a 2.1 branch is warranted. There's
still a lot that can, and should be done in 2.0. If it means an API
change, well, if the need is strong enough, then that's that. My
concern about the API was a growing tendency towards being able to
justify an API change for anything.

People *want* to use 2.0: let's make it easy for them.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

Re: Auth: Start the httpd-2.1 branch finally?

[Justin Erenkrantz]

--On Sunday, October 13, 2002 12:30 PM -0500 "William A. Rowe, Jr." 
<[EMAIL PROTECTED]> wrote:

> So far, Two Bills beg that we defer the auth reorg to 2.1.  If I
> hear three,  I will consider it appropriate to veto the auth
> reorganization for 2.0, until  we start 2.1.  The technical
> justification would be unreasonable support  traffic (via bugzilla,
> user lists, etc) in response to administrators as they are forced
> through this update.  Technically, a reasonable demand for a
> version point bump, but not reasonable within a subversion point
> bump.

I hereby challenge your 'technical' reason for a veto.  Unlike APR, 
httpd does not have a documented versioning system.  Therefore, I 
don't believe there is any expectation to break.  And, when we 
conducted the vote, I explicitly mentioned that we might break 
backwards compatibility - the rest of the group didn't seem to have a 
problem with that.

If someone else says your reason is technically valid, our rules 
states that the veto stands.  Fine, but I want to see someone else 
agree.  I think Greg and myself have tried to clarify FirstBill's 
misunderstanding of what changed.  -- justin

Re: cache+ proxy, chunked + C-L,browsers unable to display documents

[William A. Rowe, Jr.]

That's because I'm simply fixing a compiler emit.  I'm afraid I'm totally
unqualified to judge your patch, since I haven't spent any time to grok
the experimental/mod_cache work.

I'm certain the maintainers will offer feedback to my commit, and
review your patch, as they have available cycles.

Bill

At 02:50 PM 10/13/2002, you wrote:
>Hi,
>
>I've just seen you are commiting patch to mod_cache...
>I haven't received answer for my post on dev@ about the chunk/CL
>problem... Could you tell me what do you think about to let me know how
>can I code a good patch against the problem.
>
>Regards,
>
>Estrade Matthieu 
>
>
>__
>Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros
>d'économies ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant 

Re: Auth: Start the httpd-2.1 branch finally?

[William A. Rowe, Jr.]

At 04:36 PM 10/13/2002, Justin Erenkrantz wrote:
>--On Sunday, October 13, 2002 3:59 AM -0700 Greg Stein <[EMAIL PROTECTED]> wrote:
>
>>There were some directive changes, and certainly some different
>>modules to load, but nothing in the API department. Moreover, I
>>think we can deal with the directives and create some kind of
>>backwards-compat stuff. It is just that I'm not entirely sure what
>>got dropped and added yet. The modules are a bit tougher. We could
>>potentially fix it with hacks to the module loading stuff to key
>>off the old names and load the new stuff, but that just feels
>>fugly...
>
>My belief is that the only change is in the *Authoritative directives - we're now 
>more granular as we can selectively control authoritativeness on authn and authz 
>modules.  There are also some gotchas on the LoadModule lines, but, like you, I'm not 
>really sure what we can do about that.  I think the best thing to do is to document 
>the module renames.

I challenge you to do so; document both the old and the new so that

   http://httpd.apache.org/docs-2.0/

clearly documents both the pre-new-auth and post-new-auth.  I'm presuming
it can't be done -well-, because it hasn't been done.  I grappled with the idea
this weekend and surrendered.  That's when I revisited my original vote to 
implement this in 2.1 ... like FirstBill offered, I too should have hollered louder.
But no users have been harmed, and the code will go in (to 2.0 or 2.1).

The fact that we don't know what to do about it speaks volumes as to how
difficult this is, and how ill advised this restructuring is for 2.0.

Of course we can announce to the world "Hey, we were kidding, 2.0 wasn't
GA quality, but now it is, and 2.0.47 is the real GA release."  [I'm being
tongue in cheek here, I believe along with many developers that 2.0 was as
ready for GA as it was ever going to be.  We couldn't begin to track down 
the obscure bits without some adopters telling us exactly what was wrong.]

>And, solutions like adding back mod_access or mod_auth can't work since we do not 
>allow modules to share directives - therefore, there will be confusion internally 
>about which modules should handle the authorization when both are loaded.  That's 
>badness.  -- justin

Of course not.  Either the revamped auth goes it, or it's reverted. I agree
it's too difficult to have both.

Bill

Re: apache 2.0.43: %b not showing "bytes sent" but "bytes requested"

[Bojan Smojver]

On Sat, 2002-10-12 at 20:19, Bojan Smojver wrote:

> r->bytes_sent =
>   (total bytes sent) - ( (total size of brigades) - (content length) )

Actually, I think this maths wouldn't work for SSL because content
length is calculated before it. Hmm...

Bojan

Re: Auth: Start the httpd-2.1 branch finally?

[Justin Erenkrantz]

--On Sunday, October 13, 2002 3:59 AM -0700 Greg Stein 
<[EMAIL PROTECTED]> wrote:

> The API *is* stable. The auth changes did nothing to the API except
> to expand it a bit for *new* auth systems. Existing auth modules are
> unaffected.

Exactly - we only reorganized our aaa modules.  No hooks or APIs were 
modified.  Third-party aaa modules require no changes - in fact, our 
own experimental auth_ldap hasn't been converted (mainly because it 
is so many files).

> There were some directive changes, and certainly some different
> modules to load, but nothing in the API department. Moreover, I
> think we can deal with the directives and create some kind of
> backwards-compat stuff. It is just that I'm not entirely sure what
> got dropped and added yet. The modules are a bit tougher. We could
> potentially fix it with hacks to the module loading stuff to key
> off the old names and load the new stuff, but that just feels
> fugly...

My belief is that the only change is in the *Authoritative directives 
- we're now more granular as we can selectively control 
authoritativeness on authn and authz modules.  There are also some 
gotchas on the LoadModule lines, but, like you, I'm not really sure 
what we can do about that.  I think the best thing to do is to 
document the module renames.

And, solutions like adding back mod_access or mod_auth can't work 
since we do not allow modules to share directives - therefore, there 
will be confusion internally about which modules should handle the 
authorization when both are loaded.  That's badness.  -- justin

Re: Auth: Start the httpd-2.1 branch finally?

[rbb]

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
---

cache+ proxy, chunked + C-L,browsers unable to display documents

[Estrade Matthieu]

Hi,

I've just seen you are commiting patch to mod_cache...
I haven't receive answer for my post on dev@ about the chunk/CL
problem...
Could you tell me what do you think about to let me know how can I code
a godd patch against the problem.

Regards,

Estrade Matthieu


__
Etudiant: Wanadoo t'offre le Pack eXtense Haut Débit soit 150,92 euros
d'économies ! Clique ici : http://www.ifrance.com/_reloc/mail.etudiant 

Re: Auth: Start the httpd-2.1 branch finally?

[Aaron Bannert]

On Sun, Oct 13, 2002 at 06:39:28AM -0400, Jeff Stuart wrote:
> Speaking as an end user, my problem is this:
> 
> Module development.  PHP STILL does not officially support Apache 2.  It
> is still marked as experimental.  Mod_perl still doesn't support Apache
> 2.
> 
> For me, these are the 2 third party modules I use.  Yes, the onus DOES
> rest on the developers of these modules to port over.  However, if the
> API keeps changing underneath their feet... I can understand WHY it's
> taking them as long as it has to "officially" support Apache 2.0.
> 
> And now you want to create an Apache 2.1!  Oy!  Give the third party
> developers a LITTLE bit of time to catch up. :) 

As an Apache developer who has also worked on the apache2filter for
PHP, I'd like to reassure you that changing APIs have little or
no negative effect on our ability to stabilize the PHP module for
Apache 2.

-aaron

Re: mod_proxy and Content-Length

[Richard Reiner]

Well, unless someone else registers some disagreement, it appears to be
unanimous:

 proxy should not monkey wth Content-Length (more correctly, proxy
 should depend on the filters to do any required chunked/C-L fiddling,
 and the filters should be responsible for always emitting responses
 which either are chunked or have a correct C-L header)

My team has also (more than once) had to hack proxy to deal with this,
but we don't currently have a well-tested patch against 2.0.43.

Does anyone else? or should we draw straws for who gets to write it?

Richard

- Original Message -
>Subject:  Re: mod_proxy and Content-Length
>From: "Dave Seidel" <[EMAIL PROTECTED]>
>Date: 2002-10-13 16:58:11
>
>
>Pardon me for butting in here, but as someone who is building a product
>based in part upon Apache/mod_proxy, I *strongly* agree with Graham.  I've
>had to hack the mod_proxy code more than once to deal with this issue, and
>I'd rather not have to.  I agree that it should be entirely up to any
>modifying filter to be responsible for Content-Length changes.  The proxy
>itself should, IMHO, be always be considered a non-modifying passthough
>(with the obvious exception of proxy-specific HTTP headers, which
>Content-Length is not).
>
>- Dave
>
>

- Original Message -
From: "Graham Leggett" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, October 11, 2002 5:26 AM
Subject: Re: mod_proxy and Content-Length


> [EMAIL PROTECTED] wrote:
>
> > Problems with 2.0.42 and mod_proxy with Content-Length:
> >
> >   - 2.0.39 stripped C-L from all HTTP/1.0 responses.
> >   - 2.0.40 retained C-L on HTTP/1.0 responses for GETs, but stripped it
> > for HEAD.
> >   - 2.0.42 strips C-L from all HTTP/1.0 responses.
> >
> > Do people think that the 2.0.42 behaviour (stripping C-L from all
> > HTTP/1.0 responses) is correct?  The messages referenced below would
> > suggest not, but .42 has reverted to .39's behaviour.
>
> I don't think proxy should touch content-length at all.
>
> If a filter fiddles with content length, then it should be responsible
> for removing the content-length header as needed so that it can be
> readded later.
>
> Proxy doesn't change content-length in itself - so it really has no
> business touching it.
>
> Regards,
> Graham
> --
> -
> [EMAIL PROTECTED] "There's a moon
> over Bourbon Street
> tonight..."
>
>

Re: mod_blank development

[Brian Pane]

On Sun, 2002-10-13 at 04:47, fabio rohrich wrote:
> HI!
> I wrote you last time about my development of a new
> apache module.
> 
> mod_blanks: a module for the Apache web server which would on-the-fly 
> remove unnecessary blank space, comments and other non-interesting 
> things from the served page.  Skills needed: the C langugae, a bit of 
> text parsing techniques, HTML, learn Apache API.  Complexity: low to 
> moderate (after learning the API).  Usefulness: moderate to low (but 
> maybe better than that, it's a kind of nice toy topic that could be 
> shown to save a lot of bandwith on the Internet :-).
> 
> So, the question is. I'm developing it for my bachelor thesis
> and my teacher told me it's too easy to develop it.
> So, have you some ideas, like something to do more (something
> like compression) or other things to add in the module.

If you want to stick with the mod_blanks idea but make it
more more advanced (so that it's complicated enough to be
a thesis project), here are a couple of ideas:

  * Removing extra spaces/comments/etc from HTML while delivering
it is a good idea, but it's not necessarily something that
you want your web server to do on every request.  If you
deliver the same page a hundred times per day (or a hundred
times per second), it's wasteful to keep doing the same
parsing work on the same file over and over.  So one
possibility is: make the module smart enough to cache
the "optimized" versions of pages.

  * Another challenge with mod_blanks is that there is a
tradeoff between bandwidth cost and hardware cost.  If you
do a lot of processing to reduce the bytes sent (removing
extraneous spaces, compression, etc), it will reduce your
bandwidth cost, but you'll have to spend more on server
hardware.  And if your server suddenly gets a lot of
traffic, it might be able to handle the extra load, but
not if it also has to do all the mod_blanks processing
(the same idea applies to mod_deflate also).  So one idea
that might be interesting is:  Let the server administrator
define which optional filters can be skipped when the server
is heavily loaded.  (An "optional" module in this situation
would mean something that we could skip without causing a
bad response to be sent to the client.  So mod_deflate counts
as optional, for example, but mod_include doesn't.)  Then,
during request processing, decide whether to run the
optional filters based on how overloaded the server is.

  * One more idea: do some research to determine which is
faster: removing blanks and comments, or just compressing
the HTML.  Or, to put it another way, build mod_blanks and
compare its performance to mod_deflate.  Mod_blanks would
have an advantage, because it can use simpler and faster
code.  On the other hand, mod_deflate also has an advantage
because it will result in a smaller block of bytes being
written to the socket, which usually will reduce the CPU
time spent in the kernel.  Which one will win?  Or is it
better to do both: eliminate spaces and comments, and also
compress?

Brian

Re: Auth: Start the httpd-2.1 branch finally?

[William A. Rowe, Jr.]

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.

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

Re: Auth: Start the httpd-2.1 branch finally?

[William A. Rowe, Jr.]

At 05:59 AM 10/13/2002, Greg Stein wrote:
>The API *is* stable. The auth changes did nothing to the API except to
>expand it a bit for *new* auth systems. Existing auth modules are
>unaffected.

To the extent that they don't choose to use the new hooks, I believe
you are right.  Certainly no MMN major bump required.  The reorganization
is the only issue, and only from a user perspective, not a coding objection.

>There were some directive changes, and certainly some different modules to
>load, but nothing in the API department. Moreover, I think we can deal with
>the directives and create some kind of backwards-compat stuff. It is just
>that I'm not entirely sure what got dropped and added yet. The modules are a
>bit tougher. We could potentially fix it with hacks to the module loading
>stuff to key off the old names and load the new stuff, but that just feels
>fugly...

Exactly my point.  Few understand what got added and dropped.
It's a mess from an administrators point of view.

The *code* is good.  The reorganization is the hardship.  Projects shouldn't
(and most would never) demand that users reorganize their configuration
files on a subversion point bump.  

So far, Two Bills beg that we defer the auth reorg to 2.1.  If I hear three, 
I will consider it appropriate to veto the auth reorganization for 2.0, until 
we start 2.1.  The technical justification would be unreasonable support 
traffic (via bugzilla, user lists, etc) in response to administrators as
they are forced through this update.  Technically, a reasonable demand
for a version point bump, but not reasonable within a subversion point bump.

Don't get me wrong, I'm ++1 for this change to Apache 2.1, and want to
help folks develop to the new schema for Apache 2.1.  I suggest a 2.1 
branch for affected files, for now.  This makes it simple, when we officially
begin the 2.1 "Effort", to merge all the changes from the main branch
and incorporate all 2.1 changes.  Only the folks who commit code to
the 2.1 branch are committed to remerging the changes from HEAD.
Folks not interested in participating yet would not be affected by this
side branch.

I still think it's silly to insist that 2.0 be 'perfect' when we can easily
drop support of 2.0 once 2.1 it is just as ready for the prime time.
The 1.3 tree remains supported simply because it is more portable, 
the lack of thread support makes it less complex and therefore 
(so far) a bit more robust on Unix, and there is a rich history 
of modules which {won't be /or/ are still being} ported.

Other thoughts, suggestions or objections?

Bill

Re: Auth: Start the httpd-2.1 branch finally?

[rbb]

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: mod_proxy and Content-Length

[Dave Seidel]

Pardon me for butting in here, but as someone who is building a product
based in part upon Apache/mod_proxy, I *strongly* agree with Graham.  I've
had to hack the mod_proxy code more than once to deal with this issue, and
I'd rather not have to.  I agree that it should be entirely up to any
modifying filter to be responsible for Content-Length changes.  The proxy
itself should, IMHO, be always be considered a non-modifying passthough
(with the obvious exception of proxy-specific HTTP headers, which
Content-Length is not).

- Dave



- Original Message -
From: "Graham Leggett" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, October 11, 2002 5:26 AM
Subject: Re: mod_proxy and Content-Length


> [EMAIL PROTECTED] wrote:
>
> > Problems with 2.0.42 and mod_proxy with Content-Length:
> >
> >   - 2.0.39 stripped C-L from all HTTP/1.0 responses.
> >   - 2.0.40 retained C-L on HTTP/1.0 responses for GETs, but stripped it
> > for HEAD.
> >   - 2.0.42 strips C-L from all HTTP/1.0 responses.
> >
> > Do people think that the 2.0.42 behaviour (stripping C-L from all
> > HTTP/1.0 responses) is correct?  The messages referenced below would
> > suggest not, but .42 has reverted to .39's behaviour.
>
> I don't think proxy should touch content-length at all.
>
> If a filter fiddles with content length, then it should be responsible
> for removing the content-length header as needed so that it can be
> readded later.
>
> Proxy doesn't change content-length in itself - so it really has no
> business touching it.
>
> Regards,
> Graham
> --
> -
> [EMAIL PROTECTED] "There's a moon
> over Bourbon Street
> tonight..."
>
>

Re: Auth: Start the httpd-2.1 branch finally?

[rbb]

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
---

Problem with cache+proxy and multiple brigade

[Matthieu Estrade]

Hi,

I found a problem with mod_cache and mod_proxy...

when cache is storing the data + headers in memory, it doesn't care 
about Transfert-Encoding...
So if reverse proxy receive a response by multiple brigade, with the 
header Transfert-Encoding=chunked, mod_cache store it in mobj->header_out.

When cache_out serve the document from cache, it setup the 
content-length with mobj->m_len which is the len of the file stored in 
mobj->m
So if we had before the Transfer-Encoding set up, the response contains 
now these 2 headers:

Transfer-Encoding: chunked\r\n
Content-Length: 12457 \r\n

and in case of this response, the browser refuse to display the document 
(html, gif, css...etc)
I inserted these 2 lines before copying the headers (see patch) to 
delete the Transfer-Encoding in case reverse proxy receive it.

and now, the browser receive only content length and can display the 
document.
I am not sure my dirty patch is  good because i don't know all what 
Transfer-Encoding can take as value, and all impact of this header.

regards,

Estrade Matthieu




? patch_cache
Index: mod_mem_cache.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/experimental/mod_mem_cache.c,v
retrieving revision 1.85
diff -u -r1.85 mod_mem_cache.c
--- mod_mem_cache.c 2 Oct 2002 18:26:52 -   1.85
+++ mod_mem_cache.c 12 Oct 2002 14:58:46 -
@@ -819,6 +819,12 @@
 mem_cache_object_t *mobj = (mem_cache_object_t*) obj->vobj;
 int rc;
  
+/* Delete Transfer-Encoding if present, coming from reverse proxy */
+
+if (apr_table_get(r->headers_out,"Transfer-Encoding")){
+   apr_table_unset(r->headers_out,"Transfer-Encoding");
+}
+ 
 /*
  * The cache needs to keep track of the following information: 
  * - Date, LastMod, Version, ReqTime, RespTime, ContentLength 

Re: apache 2.0.43: %b not showing "bytes sent" but "bytes requested"

[Bojan Smojver]

Funny enough, there is a variable called unused_bytes_sent in that
function - kind of makes it obvious it's not being used ;-)

I thought that making f->r non-NULL was rejected due to complications
with other protocols that don't understand requests? Anyway, we don't
really need to store anything in request, we just need to retrieve from
connection, log it and then reset the counters.

Instead of introducing more fields to conn_rec (to prevent another MMN
bump), why don't we use the same thing you suggested for mod_logio,
which is putting the counting structure of core_output_filter into
f->c->conn_config? This structure would not be a mod_logio option, but
rather always there. mod_logio would then just use it to log. Or, even
better, all the logging would be done through mod_log_config, which
would make mod_logio redundant. By the same token, the input counting
could also go into core_input_filter...

Bojan

On Sat, 2002-10-12 at 13:21, [EMAIL PROTECTED] wrote:
> 
> 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

Re: Auth: Start the httpd-2.1 branch finally?

[William A. Rowe, Jr.]

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.

>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.

>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.

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.

Bill

Re: Auth: Start the httpd-2.1 branch finally?

[rbb]

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?

[Jim Jagielski]

[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

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

Re: Auth: Start the httpd-2.1 branch finally?

[rbb]

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?

[rbb]

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 9461

Re: Auth: Start the httpd-2.1 branch finally?

[johannes m. richter]

>Anyway, I've most likely upset a few people, and I apologize in
>advance. Just take these words from someone who *still* wants Apache
>to achieve world domination :)

As a user I'll try to help achiving this goal ;)

About the specific issue: I (again as a user) like the idea of at least 
putting the old auth modules in the coming 2.0 releases, so that 
compatibility between the minor releases - which certainly is important for 
adoption - is not broken and a smoother transistion to the newer - and 
probably better - auth module design gets possible.
On the other hand I am just a little user so I don't really know what 
disadvantages this may have (except that people stay with the old auth 
modules forever;)

just my 2€cents :-)
..nice weekend & cheers
johannes

-- 
A woman without a man is like a fish without a bicycle.
- http://jgcl.at/ko/ - new photos from summer camp 2002 in Moosen/Tirol

apache test suite?

[David Burry]

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

Re: Auth: Start the httpd-2.1 branch finally?

[Jim Jagielski]

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 know some of this is not germane to
the current question and issue, but some of it is.

Recall that when all this started, we were users who developed
because we were users; we weren't developers who simply used what we
developed. It was real, not an programming exercise.

Anyway, I've most likely upset a few people, and I apologize in
advance. Just take these words from someone who *still* wants Apache
to achieve world domination :)
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

RE: Auth: Start the httpd-2.1 branch finally?

[Sander Striker]

> From: Aaron Bannert [mailto:[EMAIL PROTECTED]]
> Sent: 12 October 2002 22:18

> On Sat, Oct 12, 2002 at 10:37:07AM -0700, Justin Erenkrantz 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.
> 
> That seems like a one-way street to me. How come it's ok to work on the
> auth changes in 2.0 but it's not ok for others?

The auth changes were complete before they were applied in the sense that
they didn't leave the tree in a broken state.
 
> > These changes 
> > shouldn't be held up by the fact that we don't have a 2.1 yet.
> 
> I agree, as a matter of fact, I don't think any changes should be held
> up for any reason whatsoever.


Sander

Re: Branch Philosophy

[Glenn]

On Sat, Oct 12, 2002 at 11:41:01PM -0400, Tim Wilde wrote:
> I'll preface this by saying I'm not much of a developer myself, but I use
> a number of major open source software packages, and follow their
> development models pretty closely.
> 
> I don't understand all this fighting about branching and development.  I
> don't understand why Apache 2.0 has been released, and recommended for
> production use, if, as many seem to be saying, it isn't
> "feature-complete".  Every other project I've ever seen doesn't do active
> development on a released branch.  That's just NOT how to do things. [...]

Let me preface my response by saying that I am not running Apache2 in
production (module reasons), although I run it in my test lab.  In the
1.3 tree, I watch the releases and see what has changed.  Not all Apache
point releases reach GA.  And a few that do occasionally shouldn't have.
That's just the way it is, even with proprietary software.  But being
open source, I can gauge things much better in Apache by following the
development.

The same thing goes for RedHat releases.  I know a lot of people who
won't touch RedHat *.0 releases.  Historically, the *.0 releases include
major changes.  RedHat has done an excellent job with each release, but
the *.0 releases have typically needed more initial fixes than the rest.
Why is this?  RedHat does rigorous testing on its releases, but only once
it is being used by a much wider audience do more subtle bugs show up
(often related to the major changes that fewer people were previously using)
This has the effect of pushing the envelope a bit, which I like (gcc and
glibc upgrades, for example).

I look at Apache the same way.  Apache2 includes some _major_ changes.
These changes are not going to stabilize until they are used by a wider
audience.  At last post of the count to this list, slightly more than
6,000 servers were running Apache2 (did I get that right?)  Therefore,
changing the API at this early stage in order to move towards a solid
2.0 platform is a Good Thing (tm), even if it means the many changes
restrict the growth of Apache2 to early adopters.  It's much better than
withholding those changes and slowing down progress.  And growing the
Apache2 userbase slowly as the 2.0 platform stabilizes is also much
better than wholesale adoption by general users who often do not maintain
their systems as well as early adopters, and who might be slow in 
updating to important releases.

Don't misunderstand: Apache2 works today!  It just isn't everything to
everyone yet since some module authors need to catch up to the new Apache
model.

Just a counterpoint.
Cheers,
-Glenn
(who normally doesn't post this much, but has something to contribute)

Re: Auth: Start the httpd-2.1 branch finally?

[Justin Erenkrantz]

--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

Re: Auth: Start the httpd-2.1 branch finally?

[Justin Erenkrantz]

--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

Re: cvs commit: httpd-2.0/server log.c

[William A. Rowe, Jr.]

At 10:35 PM 10/12/2002, [EMAIL PROTECTED] wrote:
>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.

EAI (not EAP, sorry) are gethostname API specific errors.  The point is, 
we could lookup the (EAI 12): error from the platform's netdb.h and know
what it is, trying to grok (75012) is goofy.  But since I'm not terribly
affected by this, feel free to drop the EAI bit if you object strongly.

Jeff is most likely to have an opinion on EAI specifically.

Bill

Re: Auth: Start the httpd-2.1 branch finally?

[Aaron Bannert]

On Sat, Oct 12, 2002 at 10:37:07AM -0700, Justin Erenkrantz 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.

That seems like a one-way street to me. How come it's ok to work on the
auth changes in 2.0 but it's not ok for others?

> These changes 
> shouldn't be held up by the fact that we don't have a 2.1 yet.

I agree, as a matter of fact, I don't think any changes should be held
up for any reason whatsoever.

-aaron

Re: Auth: Start the httpd-2.1 branch finally?

[rbb]

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?

[Greg Stein]

On Sat, Oct 12, 2002 at 11:23:23PM -0400, Bill Stoddard wrote:
> > On Sat, Oct 12, 2002 at 10:37:07AM -0700, Justin Erenkrantz 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.
> >
> > That seems like a one-way street to me. How come it's ok to work on the
> > auth changes in 2.0 but it's not ok for others?
> 
> I didn't make enough noise about this the first time around. I would
> like to see the auth changes taken out of 2.0 and moved into 2.1.  We need
> to stablize the API in 2.0 for a reasonable amount of time to encourage
> module authors to begin porting their modules to 2.0.

The API *is* stable. The auth changes did nothing to the API except to
expand it a bit for *new* auth systems. Existing auth modules are
unaffected.

There were some directive changes, and certainly some different modules to
load, but nothing in the API department. Moreover, I think we can deal with
the directives and create some kind of backwards-compat stuff. It is just
that I'm not entirely sure what got dropped and added yet. The modules are a
bit tougher. We could potentially fix it with hacks to the module loading
stuff to key off the old names and load the new stuff, but that just feels
fugly...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Auth: Start the httpd-2.1 branch finally?

[Jim Jagielski]

[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.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson

Re: Auth: Start the httpd-2.1 branch finally?

[Greg Stein]

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.

>...
> 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.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: apache test suite?

[David Burry]

sorry folks, I knew it would be that easy, I should have looked more closely
at the web site too  ;o)

Dave


- Original Message -
From: "Cliff Woolley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, October 12, 2002 9:50 PM
Subject: Re: apache test suite?


> 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...
>
> See the httpd-test repository.  :)
>

Re: cvs commit: httpd-2.0/server log.c

[rbb]

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

segfault in mod_negotiation.c

[Gregory (Grisha) Trubetskoy]

--- 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;
 }


Grisha

Branch Philosophy

[Tim Wilde]

I'll preface this by saying I'm not much of a developer myself, but I use
a number of major open source software packages, and follow their
development models pretty closely.

I don't understand all this fighting about branching and development.  I
don't understand why Apache 2.0 has been released, and recommended for
production use, if, as many seem to be saying, it isn't
"feature-complete".  Every other project I've ever seen doesn't do active
development on a released branch.  That's just NOT how to do things.  Yet
Apache 2.0's API is changing, it seems on a daily basis.  If this is
release software, why are you changing the API?

Examples:

mySQL - 3.23.xx is released.  Bug-fixes only.  4.0 is now in beta -
feature freeze, bug fixing for release.  4.1 is alpha, 5.0 is pre-alpha.
Those are where development is going on, use at your own risk,
back-porting major bug/security fixes to the released/stabilizing
branches.

FreeBSD - 4.7 is the current release.  Minor development occurs on the
-STABLE branch, which will lead to the release of 4.8, 4.9, etc, with a
-CURRENT branch for bleeding edge, which will become 5.0.  When 5.0 is
released, -CURRENT (which may then become -STABLE, with -CURRENT being
6.0) will be developed for 5.1, 5.2, etc.  FreeBSD "releases" never change
after they're released - point releases are made if absolutely necessary
(4.6.1 and 4.6.2, for example) and a security-patches-only CVS tag is
available for each release.

Perl - Releases are made on even numbers (5.6, 5.8) with development
happening in the next odd number (currently 5.9) which will be released as
5.10.  Changes within branches (5.6.1, 5.8.1, if/when they're made) are
for vital fixes only, and extensively tested in previous versions before
being released.

All of these projects have their own problems.  But at least their users
can know that "FreeBSD 4.7" or "Perl 5.6" is going to be the same piece of
software between 4.7.0 and 4.7.1 or 5.6.0 and 5.6.1, with only minor
changes.  That's not so with Apache 2.0.

I don't see what's so hard here.  Maybe 2.0 isn't "feature-complete" yet.
But I think it's time to give up on 2.0 and start doing things right.
Start developing full-time on 2.1.  Make it available as development
software, clearly marked as such.  Get it feature-complete.  Set goals.
Then, when the time is right, release it as 2.2.  While you're going,
backport bug fixes to 2.0 if they become necessary.  But don't make API
changes.  Don't change the heart of the software.  Heck, you shouldn't
even be making MAJOR API changes in 2.1 - PHP and Linux have both made
that mistake at different times, and many people would never touch them
again because of it.

Apache is a de-facto standard.  Don't wreck it by going around making
changes willy-nilly mid-stream and alienating your users.  Pick a
development model that doesn't have people running software that doesn't
even have functional helper applications as if it's release quality.  I'm
sorry, but a broken htpasswd binary is NOT acceptable in a GA release.  If
I'd read this list before I switched to Apache 2.0, I never would have
made the change.

I don't want to start a flamewar, and I know the first cry is going to be
"then why don't /you/ coordinate it?!"  Take my advice, or leave it.  I
don't have the time to coordinate a major software project, nor do I think
I'm capable of doing it right - certainly I couldn't do it "perfectly",
nor do I think anyone could.  I just think it can be done better than the
way it's being done here.

That's my several dollars of opinion.  Take or leave it, it's up to all of
you.  I just use the software :)  And I know there are a lot of people out
there who feel the same way I do.

Tim Wilde

-- 
Tim Wilde
[EMAIL PROTECTED]
Systems Administrator
Dynamic DNS Network Services
http://www.dyndns.org/

Re: segfault in mod_negotiation.c

[Gregory (Grisha) Trubetskoy]

Sorry - nevermind that, obviously I was being extra sloppy, here is
another stab at this.

It segafults if a translate_name doesn't set req->filename. (I don't know
how probable this is, but it did happen to someone using mod_python,
perhpas the way to solve it is to make mod_python guard against this)

The segfault will happen in mod_mime.c, line 807 in find_ct()

/* If use_path_info is explicitly set to on (value & 1 == 1), append. */
if (conf->use_path_info & 1) {
resource_name = apr_pstrcat(r->pool, r->filename, r->path_info, NULL);
}
else {
resource_name = r->filename;
}

/* Always drop the path leading up to the file name.
 */
if ((fn = ap_strrchr_c(resource_name, '/')) == NULL) {

It's not considering the possibility of r->filename being null.

Grisha

On Sat, 12 Oct 2002 [EMAIL PROTECTED] wrote:

> 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: Auth: Start the httpd-2.1 branch finally?

[Jeff Stuart]

Speaking as an end user, my problem is this:

Module development.  PHP STILL does not officially support Apache 2.  It
is still marked as experimental.  Mod_perl still doesn't support Apache
2.

For me, these are the 2 third party modules I use.  Yes, the onus DOES
rest on the developers of these modules to port over.  However, if the
API keeps changing underneath their feet... I can understand WHY it's
taking them as long as it has to "officially" support Apache 2.0.

And now you want to create an Apache 2.1!  Oy!  Give the third party
developers a LITTLE bit of time to catch up. :) 

On Sat, 2002-10-12 at 20:17, William A. Rowe, Jr. wrote:
> How's this for simple?  Create httpd-2.1 and back out Justin's changes
> from httpd-2.0 so we don't break our users.  If someone wants to change
> more APIs in httpd-2.1, let them do so.  When it's ready, we release it and
> start supporting it just as httpd-2.0.  We effectively drop httpd-2.0 at the
> release of httpd-2.1 except for security patches, and anything anybody
> really wants to commit.  But the focus is on the last GA code, just as
> today.  {Sure little bugs get fixed occasionally in apache-1.3.  Nothing's
> wrong with that, or with continuing that tradition in httpd-2.0.}
> 
> What's defined as 'ready' for httpd-2.1?  That it works, that it is a GA
> quality release.  If we can fix other foobars we made while designing 2.0,
> that would be terrific.  Bugs fixed in the httpd-2.0 tree can be committed
> to the httpd-2.1 tree.  But let's set our sights on an early release, some
> time this winter if not by year end.
> 
> Perhaps what scares some developers is the HUGE time between the
> idea of 2.0 and it's eventual GA release.  There is no reason we should
> get bogged down agian.  Sure, there is a quick alpha-beta-GA cycle, 
> but we have that down to a science.
> 
> Bill
-- 
Jeff Stuart <[EMAIL PROTECTED]>



signature.asc
Description: This is a digitally signed message part

Re: Problem with non-blocking write to pipe

[Takashima, Makoto]

One correction.

On Sun, 13 Oct 2002 20:40:21 +0900, [EMAIL PROTECTED] wrote:
> 
> /* write request of {PIPE_BUF} bytes or less may fail */
> /* because it is atomic when writing to pipe or FIFO  */
> while (rv == (apr_size_t)-1 &&
>*nbytes < PIPE_BUF && errno == EAGAIN)

it sould be :

while (rv == (apr_size_t)-1 &&
   *nbytes <= PIPE_BUF && errno == EAGAIN)

--
[EMAIL PROTECTED]

mod_blank development

[fabio rohrich]

HI!
I wrote you last time about my development of a new
apache module.

mod_blanks: a module for the Apache web server which
would on-the-fly 
remove unnecessary blank space, comments and other
non-interesting 
things from the served page.  Skills needed: the C
langugae, a bit of 
text parsing techniques, HTML, learn Apache API. 
Complexity: low to 
moderate (after learning the API).  Usefulness:
moderate to low (but 
maybe better than that, it's a kind of nice toy topic
that could be 
shown to save a lot of bandwith on the Internet :-).

So, the question is. I'm developing it for my bachelor
thesis
and my teacher told me it's too easy to develop it.
So, have you some ideas, like something to do more
(something
like compression) or other things to add in the
module.

Thanks,
F.R.

__
Mio Yahoo!: personalizza Yahoo! come piace a te 
http://it.yahoo.com/mail_it/foot/?http://it.my.yahoo.com/

RE: Auth: Start the httpd-2.1 branch finally?

[Bill Stoddard]

> On Sat, Oct 12, 2002 at 10:37:07AM -0700, Justin Erenkrantz 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.
>
> That seems like a one-way street to me. How come it's ok to work on the
> auth changes in 2.0 but it's not ok for others?

I didn't make enough noise about this the first time around. I would
like to see the auth changes taken out of 2.0 and moved into 2.1.  We need
to stablize the API in 2.0 for a reasonable amount of time to encourage
module authors to begin porting their modules to 2.0.

Bill

Re: cvs commit: httpd-2.0/modules/experimental cache_util.c

[Paul J. Reder]

Okay, this takes care of item 4 from the list below. Thanks Brian, saves
me from having to do the commit. :)

What about the other 3? Should they be fixed by the change from
apr_time_t to apr_int64_t? Apr_time_t is really apr_int64_t under
the covers and I was seeing only the lower 32 bits being set when
the variables were assigned "0" and "-1". The value was correctly
set when it was assigned APR_DATE_BAD (which has an embedded cast)
so it seems that 1-3 still need to be done.

I haven't had a chance to re-run the tests through the debugger,
but I don't think the change from apr_time_t (apr_int64_t under
the covers) to apr_int64_t is going to remove the need for 1-3.

On Fri, 2002-10-11 at 16:04, Paul J. Reder wrote:
 > I have run into a problem where the cache code randomly decides that a
 > cached entry is stale or that the last modified date is some time in
 > the future. I tracked it back to the ap_cache_check_freshness code
 > which does a lot of checking of dates.
 >
 > Some of this date checking code compares and assigns uncast numeric values
 > (such as -1) and the output of atoi() to the apr_time_t values (which are
 > long longs). The debugger showed me that only the bottom half of the
 > apr_time_t was being updated/compared.
 >
 > I would like to fix the code in the following ways (if there are no
 >   objections):
 > 1) Replace the assignments/comparisons of 0 with APR_DATE_BAD
 > 2) Have someone create a "#define APR_DATE_UNASSIGNED ((apr_time_t)-1)"
 > value in apr_date.h.
 > 3) Replace the assignments/comparisons of -1 with APR_DATE_UNASSIGNED
 > 4) Replace the atoi() calls with calls to apr_atoi64().

I can fix 1 and 3 (as shown in the patch I submitted for review) but I
need help from someone with APR commit authority to do number 2 (before
I can do 3).

Thanks,

Paul J. Reder


[EMAIL PROTECTED] wrote:

> brianp  2002/10/11 23:43:32
> 
>   Modified:modules/experimental cache_util.c
>   Log:
>   Fix a mismatch of data types: apr_time_t vs intervals measured
>   in seconds.  Also use 64-bit atoi conversions to avoid loss of
>   precision (thanks to Paul Reder for the atoi fix)
>   
>   Revision  ChangesPath
>   1.19  +9 -9  httpd-2.0/modules/experimental/cache_util.c
>   
>   Index: cache_util.c
>   ===
>   RCS file: /home/cvs/httpd-2.0/modules/experimental/cache_util.c,v
>   retrieving revision 1.18
>   retrieving revision 1.19
>   diff -u -r1.18 -r1.19
>   --- cache_util.c26 Aug 2002 16:41:56 -  1.18
>   +++ cache_util.c12 Oct 2002 06:43:32 -  1.19
>   @@ -138,7 +138,7 @@
>
>
>/* do a HTTP/1.1 age calculation */
>   -CACHE_DECLARE(apr_time_t) ap_cache_current_age(cache_info *info, const apr_time_t 
>age_value)
>   +CACHE_DECLARE(apr_int64_t) ap_cache_current_age(cache_info *info, const 
>apr_time_t age_value)
>{
>apr_time_t apparent_age, corrected_received_age, response_delay, 
>corrected_initial_age,
>   resident_time, current_age;
>   @@ -152,13 +152,13 @@
>resident_time = apr_time_now() - info->response_time;
>current_age = corrected_initial_age + resident_time;
>
>   -return (current_age);
>   +return apr_time_sec(current_age);
>}
>
>CACHE_DECLARE(int) ap_cache_check_freshness(cache_request_rec *cache, 
>request_rec *r)
>{
>   -apr_time_t age, maxage_req, maxage_cresp, maxage, smaxage, maxstale, minfresh;
>   +apr_int64_t age, maxage_req, maxage_cresp, maxage, smaxage, maxstale, 
>minfresh;
>const char *cc_cresp, *cc_req, *pragma_cresp;
>const char *agestr = NULL;
>char *val;
>   @@ -202,7 +202,7 @@
>/* TODO: pragma_cresp not being used? */
>pragma_cresp = apr_table_get(r->headers_out, "Pragma");  
>if ((agestr = apr_table_get(r->headers_out, "Age"))) {
>   -age_c = atoi(agestr);
>   +age_c = apr_atoi64(agestr);
>}
>
>/* calculate age of object */
>   @@ -210,19 +210,19 @@
>
>/* extract s-maxage */
>if (cc_cresp && ap_cache_liststr(cc_cresp, "s-maxage", &val))
>   -smaxage = atoi(val);
>   +smaxage = apr_atoi64(val);
>else
>smaxage = -1;
>
>/* extract max-age from request */
>if (cc_req && ap_cache_liststr(cc_req, "max-age", &val))
>   -maxage_req = atoi(val);
>   +maxage_req = apr_atoi64(val);
>else
>maxage_req = -1;
>
>/* extract max-age from response */
>if (cc_cresp && ap_cache_liststr(cc_cresp, "max-age", &val))
>   -maxage_cresp = atoi(val);
>   +maxage_cresp = apr_atoi64(val);
>else
>maxage_cresp = -1;
>
>   @@ -238,13 +238,13 @@
>
>/* extract max-stale */
>if (cc_req && ap_cache_liststr(cc_req, "max-stale", &val))
>   -maxstale = atoi(val);
>  

Re: Problem with non-blocking write to pipe

[Jeff Trawick]

"Takashima, Makoto" <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I found a problem with non-blocking write to pipe.
> 
> Current code (2.0.43) is as following.
> 
> 
> httpd-2.0.43/srclib/apr/file_io/unix/readwrite.c:apr_file_write()

FYI...  this discussion belongs on [EMAIL PROTECTED]  the
srclib/apr tree in the httpd-2.0 directory are a copy of the APR
project code...

> It seems assuming write request never fail when
> apr_wait_for_io_or_timeout() succeeded, but it is not true
> for pipe.
...
>   - A write request for {PIPE_BUF} or fewer bytes will have
> the following effect: If there is sufficient space
> available in the pipe, write() will transfer all the
> data and return the number of bytes requested. Otherwise,
> write() will transfer no data and return -1 with errno
> set to [EAGAIN]. 
...

boy, this sucks :)  no syscall to block until timeout occurs or we can
write the whole message...

note that most existing users of APR pipes don't care about atomic
writes...  I wonder if it is appropriate to have a pipe setting that
says that atomic is important...  if really important, I guess we'd
have to sleep before retry...  otherwise maybe we should try to write
a smaller amount to the pipe...  it would be a shame to waste our
timeslice, which could cause the reader to have to block too once the
other side is empty...

> I found this problem on HP-UX11.0 whose PIPE_BUF is 8192 with
> CGI that receive more than 8kbytes POST request.
> 
> This problem can be fixed with the following code, however I
> do not know if there is better solution other than looping.
> 
> 
> do {
> rv = write(thefile->filedes, buf, *nbytes);
> } while (rv == (apr_size_t)-1 && errno == EINTR);
> #ifdef USE_WAIT_FOR_IO
> if (rv == (apr_size_t)-1 &&
> (errno == EAGAIN || errno == EWOULDBLOCK) &&
> thefile->timeout != 0) {
> apr_status_t arv = apr_wait_for_io_or_timeout(thefile, NULL, 0);
> if (arv != APR_SUCCESS) {
> *nbytes = 0;
> return arv;
> }
> else {
> do {
> rv = write(thefile->filedes, buf, *nbytes);
> 
> /* write request of {PIPE_BUF} bytes or less may fail */
> /* because it is atomic when writing to pipe or FIFO  */
> while (rv == (apr_size_t)-1 &&
>*nbytes < PIPE_BUF && errno == EAGAIN)
> {
> apr_sleep(1);   /* sleep ~10ms */
> rv = write(thefile->filedes, buf, *nbytes);
> }
> } while (rv == (apr_size_t)-1 && errno == EINTR);
> }
> }
> #endif
> 
> 
> 
> --
> [EMAIL PROTECTED]
> 

-- 
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...

Problem with non-blocking write to pipe

[Takashima, Makoto]

Hi,

I found a problem with non-blocking write to pipe.

Current code (2.0.43) is as following.


httpd-2.0.43/srclib/apr/file_io/unix/readwrite.c:apr_file_write()

do {
rv = write(thefile->filedes, buf, *nbytes);
} while (rv == (apr_size_t)-1 && errno == EINTR);
#ifdef USE_WAIT_FOR_IO
if (rv == (apr_size_t)-1 &&
(errno == EAGAIN || errno == EWOULDBLOCK) &&
thefile->timeout != 0) {
apr_status_t arv = apr_wait_for_io_or_timeout(thefile, NULL, 0);
if (arv != APR_SUCCESS) {
*nbytes = 0;
return arv;
}
else {
do {
rv = write(thefile->filedes, buf, *nbytes);
} while (rv == (apr_size_t)-1 && errno == EINTR);
}
}
#endif


It seems assuming write request never fail when
apr_wait_for_io_or_timeout() succeeded, but it is not true
for pipe.

"The Single UNIXR Specification, Version 2" is saying :


Write requests to a pipe or FIFO will be handled the same as
a regular file with the following exceptions: 

[snip]

If the O_NONBLOCK flag is set, write() requests will be
handled differently, in the following ways: 

  - The write() function will not block the thread. 

  - A write request for {PIPE_BUF} or fewer bytes will have
the following effect: If there is sufficient space
available in the pipe, write() will transfer all the
data and return the number of bytes requested. Otherwise,
write() will transfer no data and return -1 with errno
set to [EAGAIN]. 


It means that if room on the pipe is smaller than *nbyes and
*nbytes is less than or equal to {PIPE_BUF}, write() can
fail with errno=EAGAIN and return -1, and apr_file_write()
just fails.

I found this problem on HP-UX11.0 whose PIPE_BUF is 8192 with
CGI that receive more than 8kbytes POST request.

This problem can be fixed with the following code, however I
do not know if there is better solution other than looping.


do {
rv = write(thefile->filedes, buf, *nbytes);
} while (rv == (apr_size_t)-1 && errno == EINTR);
#ifdef USE_WAIT_FOR_IO
if (rv == (apr_size_t)-1 &&
(errno == EAGAIN || errno == EWOULDBLOCK) &&
thefile->timeout != 0) {
apr_status_t arv = apr_wait_for_io_or_timeout(thefile, NULL, 0);
if (arv != APR_SUCCESS) {
*nbytes = 0;
return arv;
}
else {
do {
rv = write(thefile->filedes, buf, *nbytes);

/* write request of {PIPE_BUF} bytes or less may fail */
/* because it is atomic when writing to pipe or FIFO  */
while (rv == (apr_size_t)-1 &&
   *nbytes < PIPE_BUF && errno == EAGAIN)
{
apr_sleep(1);   /* sleep ~10ms */
rv = write(thefile->filedes, buf, *nbytes);
}
} while (rv == (apr_size_t)-1 && errno == EINTR);
}
}
#endif



--
[EMAIL PROTECTED]

Patch to vendors database

[Neil Aggarwal]

Hello:

I sent this patch to [EMAIL PROTECTED] but have seen
no traffic on the list nor have I gotten a response
from the list.  Is that list still used?

I am attaching it to this email.  Can someone
please commit it to the CVS?

Thanks,
Neil.

--
Neil Aggarwal
JAMM Consulting, Inc.(972) 612-6056, http://www.JAMMConsulting.com
Custom Internet DevelopmentWebsites, Ecommerce, Java, databases



supportdb.patch
Description: Binary data

Re: apache 2.0.43: %b not showing "bytes sent" but "bytes requested"

[Bojan Smojver]

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...

Bojan

Re: segfault in mod_negotiation.c

[rbb]

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: Auth: Start the httpd-2.1 branch finally?

[rbb]

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: Auth: Start the httpd-2.1 branch finally?

[Glenn]

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.  [...]

Combine this with what Brian Pane wrote in an earlier message:

> There's one thing about this proposal that I really like:
> It creates a schedule goal for 2.1.
>
> In the past, I've been opposed to jumping to 2.1 because
> it was so vaguely defined that one couldn't be sure if
> delaying a feature to 2.1 meant "it will be out next
> quarter" or "it will be out in a few years."  If we can
> build consensus around a 2.1 with a limited feature set
> and schedule, them I'm much more interested...

Here's how I feel:  To avoid splitting developer resources (and patience)
between trees, the 2.0 tree should be feature-complete before starting
the 2.1 tree.  (And AFAIK, no one has defined "feature-complete" for 2.0.)
Once the 2.1 tree is started, primary development (head) should be in that
tree, with features backported to 2.0/1.3 as appropriate.

While I'm not a fan of compatilibility breakage between _every_ minor
release; occasional breakage is OK when discussed and voted upon, as
happened in the case of the auth changes.

Since I haven't heard anyone say "2.0 is *DONE*", in the sense of baked,
decorated, and served , why start 2.1?

As Justin Erenkrantz said:
> Lead with the code - once the code is written or we have a plan of 
> attack, we can find a home for it. 

In other words, once the code is there, then it can be determined if the
change is radical enough to warrant 2.1.

Does this conversation sound familiar or is it just me? :-)

-Glenn

Re: segfault in mod_negotiation.c

[Jeff Trawick]

"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?

-- 
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...

Re: Auth: Start the httpd-2.1 branch finally?

[Greg Stein]

On Sun, Oct 13, 2002 at 06:39:28AM -0400, Jeff Stuart wrote:
>...
> And now you want to create an Apache 2.1!  Oy!  Give the third party
> developers a LITTLE bit of time to catch up. :) 

The presence of an httpd 2.1 would have *ZERO* effect on them supporting a
2.0 release. If anything, it would help in that we would no longer be
changing 2.0 as much.

So... I'm not sure that I agree with your statement above...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Branch Philosophy

[Greg Stein]

On Sat, Oct 12, 2002 at 11:41:01PM -0400, Tim Wilde wrote:
>...
> I don't understand all this fighting about branching and development.  I
> don't understand why Apache 2.0 has been released, and recommended for
> production use, if, as many seem to be saying, it isn't
> "feature-complete".

Apache 2.0 has all the features that most people need to run their web site.
Thus, it is quite ready for production use. The fact that some people want
to add features doesn't detract from the fact that it is useful *today*.

Your car gets you from point A to point B. It is useful, and it works quite
well in the role, so you begin to use it. But the people that make the car
want to add a rear-window wiper. That doesn't detract from its original
utility, but it now has an extra feature that you can use.

> Every other project I've ever seen doesn't do active
> development on a released branch.  That's just NOT how to do things.  Yet
> Apache 2.0's API is changing, it seems on a daily basis.  If this is
> release software, why are you changing the API?

To make it better. And no, the API is not changing on a daily basis. Here
are the latest set of entries from ap_mmn.h:

 * 20020602 (2.0.37-dev) Bucket API change (metadata buckets)
 * 20020612 (2.0.38-dev) Changed server_rec->[keep_alive_]timeout to apr time
 * 20020625 (2.0.40-dev) Changed conn_rec->keepalive to an enumeration
 * 20020628 (2.0.40-dev) Added filter_init to filter registration functions
 * 20020903 (2.0.41-dev) APR's error constants changed

I think there were more changes between 20020628 and 20020903, but they
simply didn't get recorded like they should. But nobody has bumped that
value for over a month, and it hasn't needed to be bumped. In other words,
the API has been stable for about six weeks now.

> Examples:
> 
> mySQL - 3.23.xx is released.  Bug-fixes only.  4.0 is now in beta -
>...
> FreeBSD - 4.7 is the current release.  Minor development occurs on the
>...
> Perl - Releases are made on even numbers (5.6, 5.8) with development

All of these projects have a central core of people who are defining the
feature set for each release, and have the right/ability to enforce that.
The Apache community, and httpd in particular, is not set up that way. We
do not have a central authority who defines releases, schedules, or limits
on the committers' activities. Call it good or bad, but that is our way.

>...
> I don't see what's so hard here.  Maybe 2.0 isn't "feature-complete" yet.
> But I think it's time to give up on 2.0 and start doing things right.

Right in your mind. That simply isn't how this project is organized, and I
don't see it changing any time soon.

I'm not saying you're wrong. Most of the other projects that I work on/with
have a central authority. Apache/httpd does not, so your ideas just don't
apply.

>...
> even have functional helper applications as if it's release quality.  I'm
> sorry, but a broken htpasswd binary is NOT acceptable in a GA release.  If

Gee, and nobody has ever made a mistake before. Wow. We were the first? Boy,
that totally sucks.

[ /me points out Linus' "brown paper bag" release ]

>...
> nor do I think anyone could.  I just think it can be done better than the
> way it's being done here.

Projects *can* be run better, yes. But this project is not set up that way.

Seriously, I have no problem with suggestions on how to improve stability.
But they have to match the community. I think you also needed a bit more
research on the actual rate of change in the API, and bit of simple human
forgiveness for error with the htpasswd thing. It happens.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: apache test suite?

[rbb]

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?

[William A. Rowe, Jr.]

At 04:05 PM 10/12/2002, Sander Striker wrote:
>> From: Aaron Bannert [mailto:[EMAIL PROTECTED]]
>> Sent: 12 October 2002 22:18
>
>> On Sat, Oct 12, 2002 at 10:37:07AM -0700, Justin Erenkrantz 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.
>> 
>> That seems like a one-way street to me. How come it's ok to work on the
>> auth changes in 2.0 but it's not ok for others?
>
>The auth changes were complete before they were applied in the sense that
>they didn't leave the tree in a broken state.

But this is exactly my complaint with auth.  It has STILL left the docs, 
and therefore our users in a broken state.  We've rolled two releases 
without what is otherwise good code, because of the impact on users.
In fact, we agreed that the project (we were talking about code) could
and should be broken a few weeks, maybe a month, for major changes.
It's getting on two months and still there are next to no docs for this
change.  So it's totally unreleaseable.

EVEN if the docs are done, how can they help both our 2.0-pre-auth 
and 2.0-post-auth users at the same time???  I'm objecting from a 
DOCS point of view, folks still lookup 1.3 docs on our website!
And from the CONFIG point of view ... folks need their hands held
through this upgrade.  Who has it in their plans to answer all the
bugzilla reports and redundant questions on the users@httpd lists?

It's ok to work on ANYTHING.  We are all agreeing to this.  The question
Ryan raised is, does it belong in 2.0 or 2.1.  As Jim asked, are you looking
for a playground for good ideas or do you have solid problems to solve?
I'm suggesting that 2.1 should exist today.  It took Ryan (and others) over
two years to create a GA tree.  If we continue with design-by-committee,
it's time to begin development.

>> > These changes shouldn't be held up by the fact that 
>> > we don't have a 2.1 yet.
>> 
>> I agree, as a matter of fact, I don't think any changes should be held
>> up for any reason whatsoever.

We all agree.  If we need 2.1 let's create it already.  Nobody ever said that
1.1 was 'complete' before 1.2 development began.  Nobody has ever implied
that the final subversion of any revision is "IT".  It's never "DONE".  Let's
take big changes and call them version bumps when we should.  And get
that to release state and out the door as quickly as possible.

How's this for simple?  Create httpd-2.1 and back out Justin's changes
from httpd-2.0 so we don't break our users.  If someone wants to change
more APIs in httpd-2.1, let them do so.  When it's ready, we release it and
start supporting it just as httpd-2.0.  We effectively drop httpd-2.0 at the
release of httpd-2.1 except for security patches, and anything anybody
really wants to commit.  But the focus is on the last GA code, just as
today.  {Sure little bugs get fixed occasionally in apache-1.3.  Nothing's
wrong with that, or with continuing that tradition in httpd-2.0.}

What's defined as 'ready' for httpd-2.1?  That it works, that it is a GA
quality release.  If we can fix other foobars we made while designing 2.0,
that would be terrific.  Bugs fixed in the httpd-2.0 tree can be committed
to the httpd-2.1 tree.  But let's set our sights on an early release, some
time this winter if not by year end.

Perhaps what scares some developers is the HUGE time between the
idea of 2.0 and it's eventual GA release.  There is no reason we should
get bogged down agian.  Sure, there is a quick alpha-beta-GA cycle, 
but we have that down to a science.

Bill

Re: apache test suite?

[Cliff Woolley]

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...

See the httpd-test repository.  :)