cvs commit: apache-2.0 STATUS

[sameer]

sameer  98/02/06 11:59:48

  Modified:.STATUS
  Log:
  some rain
  
  Revision  ChangesPath
  1.13  +7 -5  apache-2.0/STATUS
  
  Index: STATUS
  ===
  RCS file: /export/home/cvs/apache-2.0/STATUS,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -c -u -r1.12 -r1.13
  /usr/bin/diff: conflicting specifications of output style
  --- STATUS1998/02/06 19:54:19 1.12
  +++ STATUS1998/02/06 19:59:47 1.13
  @@ -44,7 +44,9 @@
   to add more, but try not to duplicate earlier items too much.
   
   * multithreading.  
  - Status: Brian +1, Ken +1, Dean +1, Jim +1, Paul +1
  + Status: Brian +1, Ken +1, Dean +1, Jim +1, Paul +1, Sameer +1
  + - Thread Abstraction
  +   Status: Sameer +1

   * revamped process model (Dean's proposal)
 Dean says: it's hard to do the multithreading work cleanly without
  @@ -52,7 +54,7 @@
Status: 
   
   * new layered I/O.
  - Status: Brian +1, Ken +1, Dean +1, Jim +1, Paul +1
  + Status: Brian +1, Ken +1, Dean +1, Jim +1, Paul +1, Sameer +1
   
 . sfio
Status: Dean -1 until it's shown to be thread safe (RST claims it isn't)
  @@ -75,10 +77,10 @@
Status: Ken +1
   
 . documented API
  - Status: Ken +1
  + Status: Ken +1, Sameer +1
  
 . just new API phases
  - Status: Brian +1, Jim +1 (just the "gaping holes")
  + Status: Brian +1, Jim +1, Sameer +1 (just the "gaping holes")
   
 . change API 'phase' model to use module-registered hooks rather
than a fixed static structure
  @@ -89,7 +91,7 @@
   
 . backward compatibility with 1.3 (just require a recompile)
if functions get renamed, old names retained as wrappers
  - Status: Paul +1
  + Status: Paul +1, Sameer +1
   
 . make API call syntax rational (e.g., all r*() routines list r
as their first argument, et cetera)
  
  
  

cvs commit: apache-2.0 STATUS

[dgaudet]

dgaudet 98/02/06 11:54:20

  Modified:.STATUS
  Log:
  raining really hard
  
  Revision  ChangesPath
  1.12  +13 -1 apache-2.0/STATUS
  
  Index: STATUS
  ===
  RCS file: /export/home/cvs/apache-2.0/STATUS,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- STATUS1998/02/06 15:03:21 1.11
  +++ STATUS1998/02/06 19:54:19 1.12
  @@ -55,7 +55,19 @@
Status: Brian +1, Ken +1, Dean +1, Jim +1, Paul +1
   
 . sfio
  + Status: Dean -1 until it's shown to be thread safe (RST claims it isn't)
  +
 . bstdio
  + url please?
  +
  +  . page flipping friendly, page-sized buffer oriented, zero copy I/O
  +(In this model there are functions like readbuf() which return a
  + pointer to a buffer, rather than taking a pointer to a buffer.  This
  + is a lot like how kernels actually work.  The advantage is that you
  + can get zero-copy in the user space, which is a big win for caching
  + modules of all sorts.  You can also support the "traditional" slow
  + style of stdio, which adds an extra user space copy.)
  + Status: Dean +1
   
   * API work
   
  @@ -84,7 +96,7 @@
Status: Ken +1
   
   * new configuration language
  - Status: 
  + Status: Dean +1
   
   * rewrite in C++
Status: 
  
  
  

Re: cvs commit: apache-2.0 STATUS

[Paul Sutton]

On Fri, 6 Feb 1998, Alexei Kosut wrote:
> Especially not if we need to rename all our functions (see other threads).
> And there are a number of other parts of the Apache API that really need
> to be rethought (can we say "configuration"?) Backwards compatibility with
> 1.3, either for the API or the config language or anything else, has never
> (in the year and a half we've been discussing it) been a high priority for
> 2.0.

Well, I think now is probably the time to at least think about how we are
going to support current modules in the 2.0 framework. I'm not suggesting
we should bend over backwards to make everything 100% backward compatible,
but that we should value the work that has been done by third-party module
authors and not disregard their efforts. Forcing radical changes on module
authors could devalue them and maybe hurt the prospects of them continuing
to develop Apache API modules (and move them towards, say, ISAPI where
no-compilation is necessary to use later versions of the server).

Paul

cvs commit: apache-1.3/src/include http_config.h

[pcs]

pcs 98/02/06 10:25:22

  Modified:src/include http_config.h
  Log:
  To support unloading dynamic modules, add a new element to the module
  structure: dynamic_load_handle. This contains the handle of the
  dynamically loaded module (used by mod_dll and mod_so) so it can be
  unloaded later. This is initially set to NULL by the STANDARD_MODULE_STUFF
  so no changes are needed to modules. Any shared modules built up to
  now should be rebuild (the MMN could be bumped, but I don't think many
  people will have big libraries of pre-built .so's yet. Oh, they might
  have DLL's though. Um, prehaps MMN should be bumped up).
  
  Revision  ChangesPath
  1.64  +4 -1  apache-1.3/src/include/http_config.h
  
  Index: http_config.h
  ===
  RCS file: /export/home/cvs/apache-1.3/src/include/http_config.h,v
  retrieving revision 1.63
  retrieving revision 1.64
  diff -u -r1.63 -r1.64
  --- http_config.h 1998/02/01 22:05:33 1.63
  +++ http_config.h 1998/02/06 18:25:22 1.64
  @@ -176,6 +176,8 @@
   
   const char *name;
   
  +void *dynamic_load_handle;
  +
   struct module_struct *next;
   
   /* init() occurs after config parsing, but before any children are
  @@ -254,7 +256,7 @@
*/
   
   #define MODULE_MAGIC_NUMBER 19980201
  -#define STANDARD_MODULE_STUFF MODULE_MAGIC_NUMBER, -1, __FILE__, NULL
  +#define STANDARD_MODULE_STUFF MODULE_MAGIC_NUMBER, -1, __FILE__, NULL, NULL
   
   /* Generic accessors for other modules to get at their own module-specific
* data
  @@ -279,6 +281,7 @@
   /* Finally, the hook for dynamically loading modules in... */
   
   API_EXPORT(void) add_module(module *m);
  +API_EXPORT(void) remove_module(module *m);
   API_EXPORT(int) add_named_module(const char *name);
   API_EXPORT(void) clear_module_list(void);
   API_EXPORT(const char *) find_module_name(module *m);
  
  
  

cvs commit: apache-1.3/src/main http_config.c

[pcs]

pcs 98/02/06 10:19:57

  Modified:src/main http_config.c
  Log:
  Add an API function remove_module() to remove a module structure from the
  linked list of module structures. This is called by the dynamic module
  modules (mod_dll, mod_so) when a module is unloaded. This should only ever
  be called during a restart since it invalidates per-dir and per-server
  vectors.
  
  Revision  ChangesPath
  1.96  +42 -0 apache-1.3/src/main/http_config.c
  
  Index: http_config.c
  ===
  RCS file: /export/home/cvs/apache-1.3/src/main/http_config.c,v
  retrieving revision 1.95
  retrieving revision 1.96
  diff -u -r1.95 -r1.96
  --- http_config.c 1998/02/02 22:33:31 1.95
  +++ http_config.c 1998/02/06 18:19:56 1.96
  @@ -530,6 +530,48 @@
   build_method_shortcuts();
   }
   
  +/* 
  + * remove_module undoes what add_module did. There are some caveats:
  + * when the module is removed, its slot is lost so all the current
  + * per-dir and per-server configurations are invalid. So we should
  + * only ever call this function when you are invalidating almost
  + * all our current data. I.e. when doing a restart.
  + */
  +
  +API_EXPORT(void) remove_module(module *m)
  +{
  +module *modp;
  +
  +modp = top_module;
  +if (modp == m) {
  + /* We are the top module, special case */
  + top_module = modp->next;
  +}
  +else {
  + /* Not the top module, find use. When found modp will
  +  * point to the module _before_ us in the list
  +  */
  +
  + while (modp && modp->next != m) {
  + modp = modp->next;
  + }
  + if (!modp) {
  + /* Uh-oh, this module doesn't exist */
  + aplog_error(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, NULL,
  + "Cannot remove module %s: not found in module list",
  + m->name);
  + return;
  + }
  + /* Eliminate us from the module list */
  + modp->next = modp->next->next;
  +}
  +
  +m->module_index = -1;/* simulate being unloaded, should
  +  * be unnecessary */
  +dynamic_modules--;
  +}
  +
  +
   void setup_prelinked_modules()
   {
   module **m;
  
  
  

cvs commit: apache-1.3/src/modules/standard mod_so.c

[pcs]

pcs 98/02/06 10:16:46

  Modified:src/modules/standard mod_so.c
  Log:
  Make LoadModule and LoadFile work correctly across restarts (i.e.
  by unloading the loaded modules/files, then reloading when the config
  file is read again).
  
  Add longer commentary about how to use the module (which could become
  a part of the documentation when this module become non-experimental).
  
  Properly report errors during LoadFile.
  
  Revision  ChangesPath
  1.3   +125 -36   apache-1.3/src/modules/standard/mod_so.c
  
  Index: mod_so.c
  ===
  RCS file: /export/home/cvs/apache-1.3/src/modules/standard/mod_so.c,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- mod_so.c  1998/02/04 10:22:18 1.2
  +++ mod_so.c  1998/02/06 18:16:45 1.3
  @@ -1,5 +1,5 @@
   /* 
  - * Copyright (c) 1995-1997 The Apache Group.  All rights reserved.
  + * Copyright (c) 1995-1998 The Apache Group.  All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
  @@ -51,7 +51,58 @@
*
*/
   
  -/* How to create .so files on various platforms:
  +/* 
  + * This module is used to load Apache modules at runtime. This means
  + * that the server functionality can be extended without recompiling
  + * and even without taking the server down at all!
  + *
  + * To use, you'll first need to build your module as a shared library, then
  + * update your configuration (httpd.conf) to get the Apache core to
  + * load the module at start-up.
  + *
  + * The easiest way to build a module as a shared library is to use the
  + * "SharedModule" command in the Configuration file, instead of AddModule.
  + * You should also change the file extension from .o to .so. So, for example,
  + * to build the status module as a shared library edit Configuration
  + * and change
  + *   AddModulemodules/standard/mod_status.o
  + * to
  + *   SharedModule modules/standard/mod_status.so
  + *
  + * Run Configure and make. Now Apache's httpd will _not_ include
  + * mod_status. Instead a shared library called mod_status.so will be
  + * build, in the modules/standard directory. You can build any or all
  + * modules as shared libraries like this.
  + *
  + * To use the shared module, move the .so file(s) into an appropriate
  + * directory. You might like to create a directory called "modules" under
  + * you server root for this (e.g. /usr/local/httpd/modules). 
  + *
  + * Then edit your conf/httpd.conf file, and add LoadModule lines. For
  + * example
  + *   LoadModule  status_module   modules/mod_status.so
  + *
  + * The first argument is the module's structure name (look at the
  + * end of the module source to find this). The second option is
  + * the path to the module file, relative to the server root.
  + * Put these directives right at the top of your httpd.conf file.
  + *
  + * Now you can start Apache. A message will be logged at "debug" level
  + * to your error_log to confirm that the module(s) are loaded (use
  + * "LogLevel debug" directive to get these log messages).
  + *
  + * If you edit the LoadModule directives while the server is live you
  + * can get Apache to re-load the modules by sending it a HUP or USR1
  + * signal as normal. You can use this to dynamically change the 
  + * capability of your server without bringing it down.
  + *
  + * Apache's Configure currently only creates shared modules on
  + * Linux 2 and FreeBSD systems. 
  + */
  +
  +/* More details about shared libraries:
  + *
  + * How to create .so files on various platforms:
   
  FreeBSD:
 "gcc -fpic" to compile
  @@ -120,36 +171,63 @@
   #define RTLD_LAZY 1
   #endif
   
  -/*
  - * The hard part of implementing LoadModule is deciding what to do about
  - * rereading the config files.  This proof-of-concept implementation takes 
the 
  - * cheap way out:  we only actually load the modules the first time through.
  - */
  -
  -static int been_there_done_that = 0; /* Loaded the modules yet? */
   static int have_symbol_table = 0;
   
   #ifndef NO_DLOPEN
  +
  +/* This is the cleanup for a loaded DLL. It unloads the module.
  + * This is called as a cleanup function.
  + */
  +
  +void unload_module(module *modp)
  +{
  +char mod_name[50];   /* Um, no pool, so make this static */
  +
  +/* Take a copy of the module name so we can report that it has been
  + * unloaded (since modp itself will have been unloaded). */
  +strncpy(mod_name, modp->name, 49);
  +mod_name[49] = '\0';
  +
  +remove_module(modp);
  +
  +/* The Linux manpage doesn't give any way to check the success of
  + * dlclose() */
  +dlclose(modp->dynamic_load_handle);
  +
  +aplog_error(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, NULL,
  + 

cvs commit: apache-1.3/src/main http_main.c

[pcs]

pcs 98/02/06 09:59:32

  Modified:src/main http_main.c
  Log:
  Add a dummy function containing a reference to a function defined in
  util_script.c to ensure that that file is linked into httpd. Without this,
  a httpd built with only http_core and mod_so modules would be missing
  all the Apache API functions defined in util_script.
  
  Revision  ChangesPath
  1.281 +9 -0  apache-1.3/src/main/http_main.c
  
  Index: http_main.c
  ===
  RCS file: /export/home/cvs/apache-1.3/src/main/http_main.c,v
  retrieving revision 1.280
  retrieving revision 1.281
  diff -u -r1.280 -r1.281
  --- http_main.c   1998/01/31 21:44:57 1.280
  +++ http_main.c   1998/02/06 17:59:29 1.281
  @@ -141,6 +141,15 @@
   # endif /* _DEBUG */
   #endif /* MULTITHREAD */
   
  +/* This next function is never used. It is here to ensure that if we
  + * make all the modules into shared libraries that core httpd still
  + * includes the full Apache API. Without this function the objects in
  + * main/util_script.c would not be linked into a minimal httpd.
  + */
  +static void force_library_loading(void) {
  +add_cgi_vars(NULL,NULL);
  +}
  +
   #include "explain.h"
   
   #if !defined(max)
  
  
  

Re: cvs commit: apache-2.0 STATUS

[Alexei Kosut]

On Fri, 6 Feb 1998, Paul Sutton wrote:

> On 6 Feb 1998 [EMAIL PROTECTED] wrote:
> >   +c) radically revamped API
> >   +   
> >   +d) just new API phases
> >   +   Brian +1
> 
> Um, I'm not sure how to vote on this. Personally I'd like to see (a) the
> function API left pretty much as it is, (b) the phase API radically
> updated (a la Alexei et al's proposal -- i.e. remove the module structure
> from modules etc), and (c) backward compatibility with modules written for
> 1.3.

Um... if you remove the module structure, it is physically impossible to
retain bacwards compatibility with modules written for 1.3. And I don't
think it's a good idea to try.

Especially not if we need to rename all our functions (see other threads).
And there are a number of other parts of the Apache API that really need
to be rethought (can we say "configuration"?) Backwards compatibility with
1.3, either for the API or the config language or anything else, has never
(in the year and a half we've been discussing it) been a high priority for
2.0.

Also, if, as certain threads here might be leaning, Apache 2.0 is
C++-based (I'm +0 personally - I don't mind C++, but the lack of legacy
support is a bit troubling), you pretty much have to throw the 1.x API
completely out the window.

-- Alexei Kosut <[EMAIL PROTECTED]> 
   Stanford University, Class of 2001 * Apache  *

cvs commit: apache-2.0 STATUS

[coar]

coar98/02/06 07:03:22

  Modified:.STATUS
  Log:
Woo-hoo, on a roll this morning.  Sunny, cloudless, and bitterly cold.
  
  Revision  ChangesPath
  1.11  +38 -15apache-2.0/STATUS
  
  Index: STATUS
  ===
  RCS file: /export/home/cvs/apache-2.0/STATUS,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- STATUS1998/02/06 13:49:16 1.10
  +++ STATUS1998/02/06 15:03:21 1.11
  @@ -43,28 +43,51 @@
   conservative with your votes.  Items in no particular order.  Feel free
   to add more, but try not to duplicate earlier items too much.
   
  -a) multithreading.  
  -   Brian +1, Ken +1, Dean +1, Jim +1, Paul +1
  +* multithreading.  
  + Status: Brian +1, Ken +1, Dean +1, Jim +1, Paul +1

  -b) new layered I/O.
  -   Brian +1, Ken +1, Dean +1, Jim +1, Paul +1
  +* revamped process model (Dean's proposal)
  +  Dean says: it's hard to do the multithreading work cleanly without
  +  considering a bunch of this
  + Status: 
  +
  +* new layered I/O.
  + Status: Brian +1, Ken +1, Dean +1, Jim +1, Paul +1
   
  - b1) sfio
  - b2) bstdio
  +  . sfio
  +  . bstdio
  +
  +* API work
  +
  +  . radically revamped API
  + Status: Ken +1
   
  -c) radically revamped API
  -   Ken +1
  +  . documented API
  + Status: Ken +1
  
  -d) just new API phases
  -   Brian +1, Jim +1 (just the "gaping holes")
  +  . just new API phases
  + Status: Brian +1, Jim +1 (just the "gaping holes")
  +
  +  . change API 'phase' model to use module-registered hooks rather
  + than a fixed static structure
  + Status: Ken +1
  +
  +  . clearly identify API functions by renaming them
  + Status: Ken +1
  +
  +  . backward compatibility with 1.3 (just require a recompile)
  + if functions get renamed, old names retained as wrappers
  + Status: Paul +1
   
  -e) new configuration language
  +  . make API call syntax rational (e.g., all r*() routines list r
  + as their first argument, et cetera)
  + Status: Ken +1
   
  -f) rewrite in C++
  +* new configuration language
  + Status: 
   
  -g) revamped process model (Dean's proposal)
  -   Dean says: it's hard to do (a) cleanly without considering a
  - bunch of this
  +* rewrite in C++
  + Status: 
   
   Closed issues:
   
  
  
  

Re: cvs commit: apache-2.0 STATUS

[Paul Sutton]

On 6 Feb 1998 [EMAIL PROTECTED] wrote:
>   +c) radically revamped API
>   +   
>   +d) just new API phases
>   +   Brian +1

Um, I'm not sure how to vote on this. Personally I'd like to see (a) the
function API left pretty much as it is, (b) the phase API radically
updated (a la Alexei et al's proposal -- i.e. remove the module structure
from modules etc), and (c) backward compatibility with modules written for
1.3.

Paul

cvs commit: apache-2.0 STATUS

[pcs]

pcs 98/02/06 05:49:16

  Modified:.STATUS
  Log:
  Votes
  
  Revision  ChangesPath
  1.10  +2 -2  apache-2.0/STATUS
  
  Index: STATUS
  ===
  RCS file: /export/home/cvs/apache-2.0/STATUS,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- STATUS1998/02/06 13:20:08 1.9
  +++ STATUS1998/02/06 13:49:16 1.10
  @@ -44,10 +44,10 @@
   to add more, but try not to duplicate earlier items too much.
   
   a) multithreading.  
  -   Brian +1, Ken +1, Dean +1, Jim +1
  +   Brian +1, Ken +1, Dean +1, Jim +1, Paul +1

   b) new layered I/O.
  -   Brian +1, Ken +1, Dean +1, Jim +1
  +   Brian +1, Ken +1, Dean +1, Jim +1, Paul +1
   
b1) sfio
b2) bstdio
  
  
  

cvs commit: apache-2.0 STATUS

[jim]

jim 98/02/06 05:20:09

  Modified:.STATUS
  Log:
  Hurump
  
  Revision  ChangesPath
  1.9   +6 -3  apache-2.0/STATUS
  
  Index: STATUS
  ===
  RCS file: /export/home/cvs/apache-2.0/STATUS,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- STATUS1998/02/06 10:10:23 1.8
  +++ STATUS1998/02/06 13:20:08 1.9
  @@ -44,16 +44,19 @@
   to add more, but try not to duplicate earlier items too much.
   
   a) multithreading.  
  -   Brian +1, Ken +1, Dean +1
  +   Brian +1, Ken +1, Dean +1, Jim +1

   b) new layered I/O.
  -   Brian +1, Ken +1, Dean +1
  +   Brian +1, Ken +1, Dean +1, Jim +1
  +
  + b1) sfio
  + b2) bstdio
   
   c) radically revamped API
  Ken +1
  
   d) just new API phases
  -   Brian +1
  +   Brian +1, Jim +1 (just the "gaping holes")
   
   e) new configuration language
   
  
  
  

cvs commit: apache-2.0 STATUS

[dgaudet]

dgaudet 98/02/06 02:10:25

  Modified:.STATUS
  Log:
  
  
  Revision  ChangesPath
  1.8   +4 -2  apache-2.0/STATUS
  
  Index: STATUS
  ===
  RCS file: /export/home/cvs/apache-2.0/STATUS,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- STATUS1998/02/06 02:58:40 1.7
  +++ STATUS1998/02/06 10:10:23 1.8
  @@ -44,10 +44,10 @@
   to add more, but try not to duplicate earlier items too much.
   
   a) multithreading.  
  -   Brian +1, Ken +1
  +   Brian +1, Ken +1, Dean +1

   b) new layered I/O.
  -   Brian +1, Ken +1
  +   Brian +1, Ken +1, Dean +1
   
   c) radically revamped API
  Ken +1
  @@ -60,6 +60,8 @@
   f) rewrite in C++
   
   g) revamped process model (Dean's proposal)
  +   Dean says: it's hard to do (a) cleanly without considering a
  + bunch of this
   
   Closed issues:
   
  
  
  

cvs commit: apache-1.3/src/modules/standard mod_autoindex.c mod_mime.c mod_negotiation.c

[dgaudet]

dgaudet 98/02/06 01:11:42

  Modified:src  CHANGES
   src/modules/standard mod_autoindex.c mod_mime.c
mod_negotiation.c
  Log:
  HTTP/1.1 requires x-gzip and gzip encodings be treated
  equivalent, similarly for x-compress and compress.  Apache
  now ignores a leading x- when comparing encodings.  It also
  preserves the encoding the client requests (for example if
  it requests x-gzip, then Apache will respond with x-gzip
  in the Content-Encoding header).
  
  PR:   1772
  Submitted by: Ronald Tschalaer <[EMAIL PROTECTED]>
  Reviewed by:  Dean Gaudet, Roy Fielding (concept)
  
  Revision  ChangesPath
  1.617 +9 -1  apache-1.3/src/CHANGES
  
  Index: CHANGES
  ===
  RCS file: /export/home/cvs/apache-1.3/src/CHANGES,v
  retrieving revision 1.616
  retrieving revision 1.617
  diff -u -r1.616 -r1.617
  --- CHANGES   1998/02/04 21:23:30 1.616
  +++ CHANGES   1998/02/06 09:11:36 1.617
  @@ -1,5 +1,13 @@
   Changes with Apache 1.3b4
  -  
  +
  +  *) HTTP/1.1 requires x-gzip and gzip encodings be treated
  + equivalent, similarly for x-compress and compress.  Apache
  + now ignores a leading x- when comparing encodings.  It also
  + preserves the encoding the client requests (for example if
  + it requests x-gzip, then Apache will respond with x-gzip
  + in the Content-Encoding header).
  + [Ronald Tschalaer <[EMAIL PROTECTED]>] PR#1772
  +
 *) Fix a memory leak on keep-alive connections.  [Igor Tatarinov]
   
 *) Added mod_so module to support dynamic loading of modules on Unix
  
  
  
  1.66  +12 -0 apache-1.3/src/modules/standard/mod_autoindex.c
  
  Index: mod_autoindex.c
  ===
  RCS file: /export/home/cvs/apache-1.3/src/modules/standard/mod_autoindex.c,v
  retrieving revision 1.65
  retrieving revision 1.66
  diff -u -r1.65 -r1.66
  --- mod_autoindex.c   1998/01/29 20:36:11 1.65
  +++ mod_autoindex.c   1998/02/06 09:11:39 1.66
  @@ -176,6 +176,12 @@
   if (cmd->info == BY_PATH)
if (!strcmp(to, "**DIRECTORY**"))
to = "^^DIRECTORY^^";
  +if (cmd->info == BY_ENCODING) {
  + str_tolower(to);
  + if (to[0] == 'x' && to[1] == '-') {
  + to += 2;
  + }
  +}
   
   push_item(((autoindex_config_rec *) d)->alt_list, cmd->info, to, 
cmd->path, alt);
   return NULL;
  @@ -199,6 +205,12 @@
   if (cmd->info == BY_PATH)
if (!strcmp(to, "**DIRECTORY**"))
to = "^^DIRECTORY^^";
  +if (cmd->info == BY_ENCODING) {
  + str_tolower(to);
  + if (to[0] == 'x' && to[1] == '-') {
  + to += 2;
  + }
  +}
   
   push_item(((autoindex_config_rec *) d)->icon_list, cmd->info, to, 
cmd->path,
  iconbak);
  
  
  
  1.30  +2 -0  apache-1.3/src/modules/standard/mod_mime.c
  
  Index: mod_mime.c
  ===
  RCS file: /export/home/cvs/apache-1.3/src/modules/standard/mod_mime.c,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- mod_mime.c1998/01/13 23:11:23 1.29
  +++ mod_mime.c1998/02/06 09:11:39 1.30
  @@ -127,6 +127,8 @@
   {
   if (*ext == '.')
   ++ext;
  +if ((enc[0] == 'x' || enc[0] == 'X') && enc[1] == '-')
  +enc += 2;
   table_set(m->encoding_types, ext, enc);
   return NULL;
   }
  
  
  
  1.67  +9 -3  apache-1.3/src/modules/standard/mod_negotiation.c
  
  Index: mod_negotiation.c
  ===
  RCS file: /export/home/cvs/apache-1.3/src/modules/standard/mod_negotiation.c,v
  retrieving revision 1.66
  retrieving revision 1.67
  diff -u -r1.66 -r1.67
  --- mod_negotiation.c 1998/01/27 10:00:44 1.66
  +++ mod_negotiation.c 1998/02/06 09:11:40 1.67
  @@ -1468,7 +1468,6 @@
   return;
   }
   
  -
   /* if no Accept: header, leave quality alone (will
* remain at the default value of 1) */
   if (neg->accept_encodings->nelts == 0) {
  @@ -1483,9 +1482,14 @@
*/
   for (i = 0; i < neg->accept_encodings->nelts; ++i) {
   char *name = accept_recs[i].type_name;
  +int off = 0;
  +
  + if (name[0] == 'x' && name[1] == '-')
  +off = 2;
   
  -if (!strcmp(name, enc)) {
  +if (!strcmp(name+off, enc)) {
   variant->encoding_quality = 1;
  +variant->content_encoding = name;
   return;
   }
   }
  @@ -2192,7 +2196,9 @@
   r->filename = sub_req->filename;
   r->handler = sub_req->handler;
   r->content_type = sub_req->content_type;
  -r->content_encoding = sub_req->content_encoding;
  +/* it may have been modified, so that it would match the exact encoding
  + * requested by the client (i.e.

cvs commit: apache-2.0 STATUS

[coar]

coar98/02/05 18:58:40

  Modified:.STATUS
  Log:
Tra la la..
  
  Revision  ChangesPath
  1.7   +10 -9 apache-2.0/STATUS
  
  Index: STATUS
  ===
  RCS file: /export/home/cvs/apache-2.0/STATUS,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- STATUS1998/02/06 02:35:12 1.6
  +++ STATUS1998/02/06 02:58:40 1.7
  @@ -21,35 +21,36 @@
   
   Open issues:
   
  -  Replace the current Unix compilation model (Configuration.tmpl, home-brew
  +  * Replace the current Unix compilation model (Configuration.tmpl, home-brew
   Configure script) with the "autoconf toolset".
  -  Status: Brian +1, Roy +1, Dean +1
  + Status: Brian +1, Roy +1, Dean +1
   
  -  Investigate replacing the current Unix compilation model 
(Configuration.tmpl
  +  * Investigate replacing the current Unix compilation model 
(Configuration.tmpl
   home-brew Configure script) with the "autoconf toolset". (this
   varies from the above such that if it's shown that the "autoconf
   toolset" can do what we want, with less headache than what we
   have, then we go for it)
  -  Status: Jim +1
  + Status: Jim +1, Ken +1
   
  -  The "autoconf toolset" should include all three: autoconf, automake, and 
  +  * The "autoconf toolset" should include all three: autoconf, automake, and 
   libtool.
  -  Status: Brian +1, Jim +1, Roy +1, Dean +1
  + Status: Brian +1, Jim +1, Roy +1, Dean +1, Ken +1
   
 FEATURE SET FOR 2.0
  -  Here, we decide how many of the following feature ideas we will set for
  +Here, we decide how many of the following feature ideas we will set for
   ourselves as work items for 2.0.  We can't do everything we would want
   to, otherwise 2.0 will never be released.  So please try and be 
   conservative with your votes.  Items in no particular order.  Feel free
   to add more, but try not to duplicate earlier items too much.
   
   a) multithreading.  
  -   Brian +1
  +   Brian +1, Ken +1

   b) new layered I/O.
  -   Brian +1
  +   Brian +1, Ken +1
   
   c) radically revamped API
  +   Ken +1
  
   d) just new API phases
  Brian +1
  
  
  

cvs commit: apache-2.0 STATUS

[brian]

brian   98/02/05 18:35:13

  Modified:.STATUS
  Log:
  Added a section for helping narrow down the feature set for Apache 2.0.
  Please vote!
  
  Also, I added Dean's votes on the config issue, at least how I think he voted.
  
Brian
  
  Revision  ChangesPath
  1.6   +26 -2 apache-2.0/STATUS
  
  Index: STATUS
  ===
  RCS file: /export/home/cvs/apache-2.0/STATUS,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- STATUS1998/02/05 19:23:28 1.5
  +++ STATUS1998/02/06 02:35:12 1.6
  @@ -23,7 +23,7 @@
   
 Replace the current Unix compilation model (Configuration.tmpl, home-brew
   Configure script) with the "autoconf toolset".
  -  Status: Brian +1, Roy +1
  +  Status: Brian +1, Roy +1, Dean +1
   
 Investigate replacing the current Unix compilation model 
(Configuration.tmpl
   home-brew Configure script) with the "autoconf toolset". (this
  @@ -34,7 +34,31 @@
   
 The "autoconf toolset" should include all three: autoconf, automake, and 
   libtool.
  -  Status: Brian +1, Jim +1, Roy +1
  +  Status: Brian +1, Jim +1, Roy +1, Dean +1
  +
  +  FEATURE SET FOR 2.0
  +  Here, we decide how many of the following feature ideas we will set for
  +ourselves as work items for 2.0.  We can't do everything we would want
  +to, otherwise 2.0 will never be released.  So please try and be 
  +conservative with your votes.  Items in no particular order.  Feel free
  +to add more, but try not to duplicate earlier items too much.
  +
  +a) multithreading.  
  +   Brian +1
  + 
  +b) new layered I/O.
  +   Brian +1
  +
  +c) radically revamped API
  +   
  +d) just new API phases
  +   Brian +1
  +
  +e) new configuration language
  +
  +f) rewrite in C++
  +
  +g) revamped process model (Dean's proposal)
   
   Closed issues: