cvs commit: apache-1.3/src/main http_core.c
coar98/07/23 03:46:25
Modified:src/main http_core.c
Log:
Add a comment explaining the initially astonishing use of '!='
in what otherwise looks like it should be a string comparison.
Revision ChangesPath
1.213 +9 -3 apache-1.3/src/main/http_core.c
Index: http_core.c
===
RCS file: /export/home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.212
retrieving revision 1.213
diff -u -r1.212 -r1.213
--- http_core.c 1998/07/13 11:32:39 1.212
+++ http_core.c 1998/07/23 10:46:23 1.213
@@ -1087,12 +1087,18 @@
static const char *end_nested_section(cmd_parms *cmd, void *dummy)
{
if (cmd-end_token == NULL) {
- return ap_pstrcat(cmd-pool, cmd-cmd-name,
- without matching , cmd-cmd-name + 2, section, NULL);
+return ap_pstrcat(cmd-pool, cmd-cmd-name,
+without matching , cmd-cmd-name + 2,
+section, NULL);
}
+/*
+ * This '!=' may look weird on a string comparison, but it's correct --
+ * it's been set up so that checking for two pointers to the same datum
+ * is valid here. And faster.
+ */
if (cmd-cmd-name != cmd-end_token) {
return ap_pstrcat(cmd-pool, Expected , cmd-end_token, but saw ,
- cmd-cmd-name, NULL);
+ cmd-cmd-name, NULL);
}
return cmd-end_token;
}
cvs commit: apache-1.3/src/modules/standard mod_rewrite.c mod_rewrite.h
coar98/07/23 04:34:02
Modified:src/modules/standard mod_rewrite.c mod_rewrite.h
Log:
Add some capability for setting the Vary response field when
mod_rewrite makes changes based upon request fields. This is
by no means a complete treatment of the problem (redirects don't
inherit the Vary at the moment, for instance), but at least
we're not ignoring Vary here completely any more.
PR: 1644
Reviewed by: Ralf Engelschall
Revision ChangesPath
1.126 +20 -0 apache-1.3/src/modules/standard/mod_rewrite.c
Index: mod_rewrite.c
===
RCS file: /export/home/cvs/apache-1.3/src/modules/standard/mod_rewrite.c,v
retrieving revision 1.125
retrieving revision 1.126
diff -u -r1.125 -r1.126
--- mod_rewrite.c 1998/07/18 15:30:46 1.125
+++ mod_rewrite.c 1998/07/23 11:34:00 1.126
@@ -1728,6 +1728,7 @@
{
char *uri;
char *output;
+const char *vary;
char newuri[MAX_STRING_LEN];
char env[MAX_STRING_LEN];
regex_t *regexp;
@@ -1841,6 +1842,7 @@
/* One condition is false, but another can be
* still true, so we have to continue...
*/
+ ap_table_unset(r-notes, VARY_KEY_THIS);
continue;
}
else {
@@ -1866,13 +1868,30 @@
break;
}
}
+ vary = ap_table_get(r-notes, VARY_KEY_THIS);
+ if (vary != NULL) {
+ ap_table_merge(r-notes, VARY_KEY, vary);
+ ap_table_unset(r-notes, VARY_KEY_THIS);
+ }
}
/* if any condition fails the complete rule fails */
if (failed) {
+ap_table_unset(r-notes, VARY_KEY);
+ap_table_unset(r-notes, VARY_KEY_THIS);
return 0;
}
/*
+ * Regardless of what we do next, we've found a match. Check to see
+ * if any of the request header fields were involved, and add them
+ * to the Vary field of the response.
+ */
+if ((vary = ap_table_get(r-notes, VARY_KEY)) != NULL) {
+ap_table_merge(r-headers_out, Vary, vary);
+ ap_table_unset(r-notes, VARY_KEY);
+}
+
+/*
* If this is a pure matching rule (`RewriteRule pat -')
* we stop processing and return immediately. The only thing
* we have not to forget are the environment variables
@@ -3718,6 +3737,7 @@
continue;
}
if (strcasecmp(hdrs[i].key, name) == 0) {
+ ap_table_merge(r-notes, VARY_KEY_THIS, name);
return hdrs[i].val;
}
}
1.56 +7 -0 apache-1.3/src/modules/standard/mod_rewrite.h
Index: mod_rewrite.h
===
RCS file: /export/home/cvs/apache-1.3/src/modules/standard/mod_rewrite.h,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56
--- mod_rewrite.h 1998/07/13 11:32:46 1.55
+++ mod_rewrite.h 1998/07/23 11:34:01 1.56
@@ -113,6 +113,13 @@
#include http_log.h
#include http_vhost.h
+/*
+ * The key in the r-notes table wherein we store our accumulated
+ * Vary values, and the one used for per-condition checks in a chain.
+ */
+#define VARY_KEY rewrite-Vary
+#define VARY_KEY_THIS rewrite-Vary-this
+
/* The NDBM support:
* We support only NDBM files.
* But we have to stat the file for the mtime,
cvs commit: apache-1.3/src CHANGES
coar98/07/23 06:45:45 Modified:src CHANGES Log: I always forget this.. PR: 1644 Revision ChangesPath 1.978 +3 -0 apache-1.3/src/CHANGES Index: CHANGES === RCS file: /export/home/cvs/apache-1.3/src/CHANGES,v retrieving revision 1.977 retrieving revision 1.978 diff -u -r1.977 -r1.978 --- CHANGES 1998/07/22 13:20:51 1.977 +++ CHANGES 1998/07/23 13:45:42 1.978 @@ -1,5 +1,8 @@ Changes with Apache 1.3.2 + *) Modify mod_rewrite to update the Vary response field if it Does + Anything based upon request fields. [Ken Coar] PR#1644 + *) Document the special APACI behavior for installation paths where ``/apache'' is appended to paths under some (well defined, of course) situations to prevent pollution of system locations with Apache files.
cvs commit: apache-1.3/src CHANGES Configuration.tmpl
rse 98/07/23 06:57:52 Modified:src CHANGES Configuration.tmpl Log: Fix document name for dso.html Revision ChangesPath 1.979 +3 -0 apache-1.3/src/CHANGES Index: CHANGES === RCS file: /export/home/cvs/apache-1.3/src/CHANGES,v retrieving revision 1.978 retrieving revision 1.979 diff -u -r1.978 -r1.979 --- CHANGES 1998/07/23 13:45:42 1.978 +++ CHANGES 1998/07/23 13:57:50 1.979 @@ -1,5 +1,8 @@ Changes with Apache 1.3.2 + *) Fix document hyperlink for dso.html in src/Configuration.tmpl + [Ralf S. Engelschall] PR#2674 + *) Modify mod_rewrite to update the Vary response field if it Does Anything based upon request fields. [Ken Coar] PR#1644 1.107 +1 -2 apache-1.3/src/Configuration.tmpl Index: Configuration.tmpl === RCS file: /export/home/cvs/apache-1.3/src/Configuration.tmpl,v retrieving revision 1.106 retrieving revision 1.107 diff -u -r1.106 -r1.107 --- Configuration.tmpl1998/07/11 16:44:33 1.106 +++ Configuration.tmpl1998/07/23 13:57:51 1.107 @@ -72,8 +72,7 @@ # knowledge on how to compile these DSO files because this is # heavily platform-dependent. The current state of supported and # explicitly unsupported platforms can be found in the file -# htdocs/manual/sharedobjects.html, under -# Supported Platforms. +# htdocs/manual/dso.html, under Supported Platforms. # # For other platforms where you want to use the DSO mechanism you # first have to make sure it supports the pragmatic dlopen()
cvs commit: apache-2.0/docs overview_aek
akosut 98/07/23 09:42:05 Added: docs overview_aek Log: Add my 2.0 overview document to CVS, where it will be maintained for all eternity. Please make changes where appropriate. Revision ChangesPath 1.1 apache-2.0/docs/overview_aek Index: overview_aek === From [EMAIL PROTECTED] Thu Jul 23 09:38:40 1998 Date: Sun, 19 Jul 1998 00:12:37 -0700 (PDT) From: Alexei Kosut [EMAIL PROTECTED] To: new-httpd@apache.org Subject: Apache 2.0 - an overview For those not at the Apache meeting in SF, and even for those who were, here's a quick overview of (my understanding of) the Apache 2.0 architecture that we came up with. I present this to make sure that I have it right, and to get opinions from the rest of the group. Enjoy. 1. Well, if we haven't released 2.0 by Christmas of 1999, it won't matter anyway. A couple of notes about this plan: I'm looking at this right now from a design standpoint, not an implementation one. If the plan herein were actually coded as-is, you'd get a very inefficient web server. But as Donald Knuth (Professor emeritus at Stanford, btw... :) points out, premature optimization is the root of all evil. Rest assured there are plenty of ways to make sure Apache 2.0 is much faster than Apache 1.3. Taking out all the slowness code, for example... :) Also, the main ideas in this document mainly come from Dean Gaudet, Simon Spero, Cliff Skolnick and a bunch of other people, from the Apache Group's meeting in San Francisco, July 2 and 3, 1998. The other ideas come from other people. I'm being vague because I can't quite remember. We should have videotaped it. I've titled the sections of this document with quotes from our meeting, but they are paraphrased from memory, so don't take them too seriously. 2. But Simon, how can you have a *middle* end? One of the main goals of Apache 2.0 is protocol independence (i.e., serving HTTP/1.1, HTTP-NG, and maybe FTP or gopher or something). Another is to rid the server of the belief that everything is a file. Towards this end, we divide the server up into three parts, the front end, the middle end, and the back end. The front end is essentially a combination of http_main and http_protocol today. It takes care of all network and protocol matters, interpreting the request, putting it into a protocol-neutral form, and (possibly) passing it off to the rest of the server. This is approximately equivalent to the part of Apache contained in Dean's flow stuff, and it also works very well in certain non-Unix-like architectures such as clustered mainframes. In addition, part of this front-end might be optionally run in kernel space, giving a very fast server indeed... The back end is what generates the content. At the back of the back end we have backing stores (Cliff's term), which contain actual data. These might represent files on a disk, entries in a database, CGI scripts, etc... The back end also consists of other modules, which can alter the request in various fashions. The objects the server acts on can be thought of (Cliff again) as a filehandle and a set of key/value pairs (metainformation). The modules are set up as filters that can alter either one of those, stacking I/O routines onto the stream of data, or altering the metainformation. The middle end is what comes between the front and back ends. Think of http_request. This section takes care of arranging the modules, backing stores, etc... into a manner so that the path of the request will result in the correct entity being delivered to the front end and sent to the client. 3. I won't embarrass you guys with the numbers for how well Apache performs compared to IIS. (on NT) For a server that was designed to handle flat files, Apache does it surprisingly poorly, compared with other servers that have been optimized for it. And the performance for non-static files is, of course, worse. While Apache is still more than fast enough for 95% of Web servers, we'd be remiss to dismiss those other 5% (they're the fun ones anyway). Another problem Apache has is its lack of a good, caching, proxy module. Put these together, along with the work Dean has done with the flow and mod_mmap_static stuff, and we realize the most important part of Apache 2.0: a built-in, all-pervasive, cache. Every part of the request process will involve caching. In the path outlined above, between each layer of the request, between each module, sits the cache, which can (when it is useful), cache the response and its metainformation - including its variance, so it knows when it is safe to give out the cached copy. This gives every opportunity to increase the speed of the server by making sure it never has to dynamically create content more
cvs commit: apache-1.3/src CHANGES
rse 98/07/23 10:31:27 Modified:src CHANGES Log: Do some litte adjustments to let Marc agree to it ;-) Revision ChangesPath 1.980 +4 -3 apache-1.3/src/CHANGES Index: CHANGES === RCS file: /export/home/cvs/apache-1.3/src/CHANGES,v retrieving revision 1.979 retrieving revision 1.980 diff -u -r1.979 -r1.980 --- CHANGES 1998/07/23 13:57:50 1.979 +++ CHANGES 1998/07/23 17:31:24 1.980 @@ -1,10 +1,11 @@ Changes with Apache 1.3.2 *) Fix document hyperlink for dso.html in src/Configuration.tmpl - [Ralf S. Engelschall] PR#2674 + [Knut A.Syed [EMAIL PROTECTED]] PR#2674 - *) Modify mod_rewrite to update the Vary response field if it Does - Anything based upon request fields. [Ken Coar] PR#1644 + *) Modify mod_rewrite to update the Vary response field if the URL rewriting + engine does any manipulations or decisions based upon request fields. + [Ken Coar] PR#1644 *) Document the special APACI behavior for installation paths where ``/apache'' is appended to paths under some (well defined, of course)
