You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@apache.org on 2001/04/18 05:53:35 UTC
cvs commit: httpd-2.0/server protocol.c
rbb 01/04/17 20:53:35
Modified: include httpd.h
modules/http config.m4 http_core.c http_protocol.c
mod_core.h
modules/loggers mod_log_config.c
server protocol.c
Log:
Move the keepalives field out of the conn_rec and into an HTTP specific
connection record. This also moves some HTTP specific back out of the
core and into the HTTP module.
Revision Changes Path
1.147 +0 -4 httpd-2.0/include/httpd.h
Index: httpd.h
===================================================================
RCS file: /home/cvs/httpd-2.0/include/httpd.h,v
retrieving revision 1.146
retrieving revision 1.147
diff -u -d -b -w -u -r1.146 -r1.147
--- httpd.h 2001/04/16 20:33:16 1.146
+++ httpd.h 2001/04/18 03:53:29 1.147
@@ -860,14 +860,10 @@
unsigned aborted:1;
/** Are we using HTTP Keep-Alive? -1 fatal error, 0 undecided, 1 yes */
signed int keepalive:2;
- /** Did we use HTTP Keep-Alive? */
- unsigned keptalive:1;
/** have we done double-reverse DNS? -1 yes/failure, 0 not yet,
* 1 yes/success */
signed int double_reverse:2;
- /** How many times have we used it? */
- int keepalives;
/** server IP address */
char *local_ip;
/** used for ap_get_server_name when UseCanonicalName is set to DNS
1.5 +3 -0 httpd-2.0/modules/http/config.m4
Index: config.m4
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/config.m4,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -b -w -u -r1.4 -r1.5
--- config.m4 2001/03/04 06:27:27 1.4
+++ config.m4 2001/04/18 03:53:30 1.5
@@ -7,5 +7,8 @@
APACHE_MODULE(http, HTTP protocol handling, $http_objects, , yes)
APACHE_MODULE(mime, mapping of file-extension to MIME, , , yes)
+if test "$enable_http" = "yes"; then
+ AC_DEFINE(AP_HTTP_ENABLED, 1, [HTTP is enabled on this server])
+fi
APACHE_MODPATH_FINISH
1.271 +148 -0 httpd-2.0/modules/http/http_core.c
Index: http_core.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/http_core.c,v
retrieving revision 1.270
retrieving revision 1.271
diff -u -d -b -w -u -r1.270 -r1.271
--- http_core.c 2001/04/11 23:37:16 1.270
+++ http_core.c 2001/04/18 03:53:30 1.271
@@ -58,6 +58,7 @@
#include "apr_strings.h"
#include "apr_thread_proc.h" /* for RLIMIT stuff */
+#include "apr_lib.h"
#define APR_WANT_STRFUNC
#include "apr_want.h"
@@ -65,6 +66,7 @@
#define CORE_PRIVATE
#include "httpd.h"
#include "http_config.h"
+#include "http_log.h"
#include "http_connection.h"
#include "http_protocol.h" /* For index_of_response(). Grump. */
#include "http_request.h"
@@ -295,6 +297,151 @@
return OK;
}
+static int read_request_line(request_rec *r)
+{
+ char l[DEFAULT_LIMIT_REQUEST_LINE + 2]; /* getline's two extra for \n\0 */
+ const char *ll = l;
+ const char *uri;
+ const char *pro;
+
+ int major = 1, minor = 0; /* Assume HTTP/1.0 if non-"HTTP" protocol */
+ int len;
+
+ /* Read past empty lines until we get a real request line,
+ * a read error, the connection closes (EOF), or we timeout.
+ *
+ * We skip empty lines because browsers have to tack a CRLF on to the end
+ * of POSTs to support old CERN webservers. But note that we may not
+ * have flushed any previous response completely to the client yet.
+ * We delay the flush as long as possible so that we can improve
+ * performance for clients that are pipelining requests. If a request
+ * is pipelined then we won't block during the (implicit) read() below.
+ * If the requests aren't pipelined, then the client is still waiting
+ * for the final buffer flush from us, and we will block in the implicit
+ * read(). B_SAFEREAD ensures that the BUFF layer flushes if it will
+ * have to block during a read.
+ */
+
+ while ((len = ap_getline(l, sizeof(l), r, 0)) <= 0) {
+ if (len < 0) { /* includes EOF */
+ /* this is a hack to make sure that request time is set,
+ * it's not perfect, but it's better than nothing
+ */
+ r->request_time = apr_time_now();
+ return 0;
+ }
+ }
+ /* we've probably got something to do, ignore graceful restart requests */
+
+ /* XXX - sigwait doesn't work if the signal has been SIG_IGNed (under
+ * linux 2.0 w/ glibc 2.0, anyway), and this step isn't necessary when
+ * we're running a sigwait thread anyway. If/when unthreaded mode is
+ * put back in, we should make sure to ignore this signal iff a sigwait
+ * thread isn't used. - mvsk
+
+#ifdef SIGWINCH
+ apr_signal(SIGWINCH, SIG_IGN);
+#endif
+ */
+
+ r->request_time = apr_time_now();
+ r->the_request = apr_pstrdup(r->pool, l);
+ r->method = ap_getword_white(r->pool, &ll);
+
+#if 0
+/* XXX If we want to keep track of the Method, the protocol module should do
+ * it. That support isn't in the scoreboard yet. Hopefully next week
+ * sometime. rbb */
+ ap_update_connection_status(AP_CHILD_THREAD_FROM_ID(conn->id), "Method", r->method);
+#endif
+ uri = ap_getword_white(r->pool, &ll);
+
+ /* Provide quick information about the request method as soon as known */
+
+ r->method_number = ap_method_number_of(r->method);
+ if (r->method_number == M_GET && r->method[0] == 'H') {
+ r->header_only = 1;
+ }
+
+ ap_parse_uri(r, uri);
+
+ /* ap_getline returns (size of max buffer - 1) if it fills up the
+ * buffer before finding the end-of-line. This is only going to
+ * happen if it exceeds the configured limit for a request-line.
+ */
+ if (len > r->server->limit_req_line) {
+ r->status = HTTP_REQUEST_URI_TOO_LARGE;
+ r->proto_num = HTTP_VERSION(1,0);
+ r->protocol = apr_pstrdup(r->pool, "HTTP/1.0");
+ return 0;
+ }
+
+ if (ll[0]) {
+ r->assbackwards = 0;
+ pro = ll;
+ len = strlen(ll);
+ } else {
+ r->assbackwards = 1;
+ pro = "HTTP/0.9";
+ len = 8;
+ }
+ r->protocol = apr_pstrndup(r->pool, pro, len);
+
+ /* XXX ap_update_connection_status(conn->id, "Protocol", r->protocol); */
+
+ /* Avoid sscanf in the common case */
+ if (len == 8 &&
+ pro[0] == 'H' && pro[1] == 'T' && pro[2] == 'T' && pro[3] == 'P' &&
+ pro[4] == '/' && apr_isdigit(pro[5]) && pro[6] == '.' &&
+ apr_isdigit(pro[7])) {
+ r->proto_num = HTTP_VERSION(pro[5] - '0', pro[7] - '0');
+ } else if (2 == sscanf(r->protocol, "HTTP/%u.%u", &major, &minor)
+ && minor < HTTP_VERSION(1,0)) /* don't allow HTTP/0.1000 */
+ r->proto_num = HTTP_VERSION(major, minor);
+ else
+ r->proto_num = HTTP_VERSION(1,0);
+
+ return 1;
+}
+
+static int http_create_request(request_rec *r)
+{
+ ap_http_conn_rec *hconn = ap_get_module_config(r->connection->conn_config, &http_module);
+ int keptalive;
+
+ hconn = apr_pcalloc(r->pool, sizeof(*hconn));
+ ap_set_module_config(r->connection->conn_config, &http_module, hconn);
+
+ if (!r->main && !r->prev && !r->next) {
+ keptalive = r->connection->keepalive == 1;
+ r->connection->keepalive = 0;
+
+ /* XXX can we optimize these timeouts at all? gstein */
+ apr_setsocketopt(r->connection->client_socket, APR_SO_TIMEOUT,
+ (int)(keptalive
+ ? r->server->keep_alive_timeout * APR_USEC_PER_SEC
+ : r->server->timeout * APR_USEC_PER_SEC));
+
+ /* Get the request... */
+ if (!read_request_line(r)) {
+ if (r->status == HTTP_REQUEST_URI_TOO_LARGE) {
+ ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, r,
+ "request failed: URI too long");
+ ap_send_error_response(r, 0);
+ ap_run_log_transaction(r);
+ return OK;
+ }
+ return DONE;
+ }
+ if (keptalive) {
+ apr_setsocketopt(r->connection->client_socket,
+ APR_SO_TIMEOUT,
+ (int)(r->server->timeout * APR_USEC_PER_SEC));
+ }
+ }
+ return OK;
+}
+
static void register_hooks(apr_pool_t *p)
{
ap_hook_pre_connection(ap_pre_http_connection,NULL,NULL,
@@ -303,6 +450,7 @@
APR_HOOK_REALLY_LAST);
ap_hook_http_method(http_method,NULL,NULL,APR_HOOK_REALLY_LAST);
ap_hook_default_port(http_port,NULL,NULL,APR_HOOK_REALLY_LAST);
+ ap_hook_create_request(http_create_request, NULL, NULL, APR_HOOK_MIDDLE);
ap_register_input_filter("HTTP_IN", ap_http_filter, AP_FTYPE_CONNECTION);
ap_register_input_filter("DECHUNK", ap_dechunk_filter, AP_FTYPE_TRANSCODE);
1.314 +4 -3 httpd-2.0/modules/http/http_protocol.c
Index: http_protocol.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.313
retrieving revision 1.314
diff -u -d -b -w -u -r1.313 -r1.314
--- http_protocol.c 2001/04/16 21:16:53 1.313
+++ http_protocol.c 2001/04/18 03:53:31 1.314
@@ -105,6 +105,7 @@
int ka_sent = 0;
int wimpy = ap_find_token(r->pool,
apr_table_get(r->headers_out, "Connection"), "close");
+ ap_http_conn_rec *hconn = ap_get_module_config(r->connection->conn_config, &http_module);
const char *conn = apr_table_get(r->headers_in, "Connection");
/* The following convoluted conditional determines whether or not
@@ -146,7 +147,7 @@
&& r->server->keep_alive
&& (r->server->keep_alive_timeout > 0)
&& ((r->server->keep_alive_max == 0)
- || (r->server->keep_alive_max > r->connection->keepalives))
+ || (r->server->keep_alive_max > hconn->keepalives))
&& !ap_status_drops_connection(r->status)
&& !wimpy
&& !ap_find_token(r->pool, conn, "close")
@@ -154,10 +155,10 @@
|| apr_table_get(r->headers_in, "Via"))
&& ((ka_sent = ap_find_token(r->pool, conn, "keep-alive"))
|| (r->proto_num >= HTTP_VERSION(1,1)))) {
- int left = r->server->keep_alive_max - r->connection->keepalives;
+ int left = r->server->keep_alive_max - hconn->keepalives;
r->connection->keepalive = 1;
- r->connection->keepalives++;
+ hconn->keepalives++;
/* If they sent a Keep-Alive token, send one back */
if (ka_sent) {
1.7 +9 -0 httpd-2.0/modules/http/mod_core.h
Index: mod_core.h
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/mod_core.h,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -b -w -u -r1.6 -r1.7
--- mod_core.h 2001/02/28 15:24:07 1.6
+++ mod_core.h 2001/04/18 03:53:31 1.7
@@ -70,6 +70,13 @@
* @package mod_core private header file
*/
+typedef struct ap_http_conn_rec ap_http_conn_rec;
+
+struct ap_http_conn_rec {
+ /** How many times have we used it? */
+ int keepalives;
+};
+
/*
* These (input) filters are internal to the mod_core operation.
*/
@@ -91,6 +98,8 @@
AP_DECLARE(int) ap_send_http_trace(request_rec *r);
int ap_send_http_options(request_rec *r);
+
+AP_DECLARE_DATA module http_module;
#ifdef __cplusplus
}
1.53 +8 -1 httpd-2.0/modules/loggers/mod_log_config.c
Index: mod_log_config.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/loggers/mod_log_config.c,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -d -b -w -u -r1.52 -r1.53
--- mod_log_config.c 2001/03/09 20:30:32 1.52
+++ mod_log_config.c 2001/04/18 03:53:33 1.53
@@ -191,6 +191,7 @@
#include "http_core.h" /* For REMOTE_NAME */
#include "http_log.h"
#include "http_protocol.h"
+#include "mod_core.h"
#if APR_HAVE_UNISTD_H
#include <unistd.h>
@@ -527,13 +528,19 @@
}
static const char *log_connection_status(request_rec *r, char *a)
{
+#ifdef AP_HTTP_ENABLED
+ ap_http_conn_rec *hconn = ap_get_module_config(r->connection->conn_config,
+ &http_module);
+#endif
if (r->connection->aborted)
return "X";
+#ifdef AP_HTTP_ENABLED
if ((r->connection->keepalive) &&
- ((r->server->keep_alive_max - r->connection->keepalives) > 0)) {
+ ((r->server->keep_alive_max - hconn->keepalives) > 0)) {
return "+";
}
+#endif
return "-";
}
1.13 +3 -136 httpd-2.0/server/protocol.c
Index: protocol.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/protocol.c,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -b -w -u -r1.12 -r1.13
--- protocol.c 2001/04/11 23:37:16 1.12
+++ protocol.c 2001/04/18 03:53:34 1.13
@@ -363,116 +363,6 @@
}
}
-static int read_request_line(request_rec *r)
-{
- char l[DEFAULT_LIMIT_REQUEST_LINE + 2]; /* getline's two extra for \n\0 */
- const char *ll = l;
- const char *uri;
- const char *pro;
-
-#if 0
- conn_rec *conn = r->connection;
-#endif
- int major = 1, minor = 0; /* Assume HTTP/1.0 if non-"HTTP" protocol */
- int len;
-
- /* Read past empty lines until we get a real request line,
- * a read error, the connection closes (EOF), or we timeout.
- *
- * We skip empty lines because browsers have to tack a CRLF on to the end
- * of POSTs to support old CERN webservers. But note that we may not
- * have flushed any previous response completely to the client yet.
- * We delay the flush as long as possible so that we can improve
- * performance for clients that are pipelining requests. If a request
- * is pipelined then we won't block during the (implicit) read() below.
- * If the requests aren't pipelined, then the client is still waiting
- * for the final buffer flush from us, and we will block in the implicit
- * read(). B_SAFEREAD ensures that the BUFF layer flushes if it will
- * have to block during a read.
- */
-
- while ((len = ap_getline(l, sizeof(l), r, 0)) <= 0) {
- if (len < 0) { /* includes EOF */
- /* this is a hack to make sure that request time is set,
- * it's not perfect, but it's better than nothing
- */
- r->request_time = apr_time_now();
- return 0;
- }
- }
- /* we've probably got something to do, ignore graceful restart requests */
-
- /* XXX - sigwait doesn't work if the signal has been SIG_IGNed (under
- * linux 2.0 w/ glibc 2.0, anyway), and this step isn't necessary when
- * we're running a sigwait thread anyway. If/when unthreaded mode is
- * put back in, we should make sure to ignore this signal iff a sigwait
- * thread isn't used. - mvsk
-
-#ifdef SIGWINCH
- apr_signal(SIGWINCH, SIG_IGN);
-#endif
- */
-
- r->request_time = apr_time_now();
- r->the_request = apr_pstrdup(r->pool, l);
- r->method = ap_getword_white(r->pool, &ll);
-
-#if 0
-/* XXX If we want to keep track of the Method, the protocol module should do
- * it. That support isn't in the scoreboard yet. Hopefully next week
- * sometime. rbb */
- ap_update_connection_status(AP_CHILD_THREAD_FROM_ID(conn->id), "Method", r->method);
-#endif
- uri = ap_getword_white(r->pool, &ll);
-
- /* Provide quick information about the request method as soon as known */
-
- r->method_number = ap_method_number_of(r->method);
- if (r->method_number == M_GET && r->method[0] == 'H') {
- r->header_only = 1;
- }
-
- ap_parse_uri(r, uri);
-
- /* ap_getline returns (size of max buffer - 1) if it fills up the
- * buffer before finding the end-of-line. This is only going to
- * happen if it exceeds the configured limit for a request-line.
- */
- if (len > r->server->limit_req_line) {
- r->status = HTTP_REQUEST_URI_TOO_LARGE;
- r->proto_num = HTTP_VERSION(1,0);
- r->protocol = apr_pstrdup(r->pool, "HTTP/1.0");
- return 0;
- }
-
- if (ll[0]) {
- r->assbackwards = 0;
- pro = ll;
- len = strlen(ll);
- } else {
- r->assbackwards = 1;
- pro = "HTTP/0.9";
- len = 8;
- }
- r->protocol = apr_pstrndup(r->pool, pro, len);
-
- /* XXX ap_update_connection_status(conn->id, "Protocol", r->protocol); */
-
- /* Avoid sscanf in the common case */
- if (len == 8 &&
- pro[0] == 'H' && pro[1] == 'T' && pro[2] == 'T' && pro[3] == 'P' &&
- pro[4] == '/' && apr_isdigit(pro[5]) && pro[6] == '.' &&
- apr_isdigit(pro[7])) {
- r->proto_num = HTTP_VERSION(pro[5] - '0', pro[7] - '0');
- } else if (2 == sscanf(r->protocol, "HTTP/%u.%u", &major, &minor)
- && minor < HTTP_VERSION(1,0)) /* don't allow HTTP/0.1000 */
- r->proto_num = HTTP_VERSION(major, minor);
- else
- r->proto_num = HTTP_VERSION(1,0);
-
- return 1;
-}
-
static void get_mime_headers(request_rec *r)
{
char field[DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2]; /* getline's two extra */
@@ -556,9 +446,6 @@
r->connection = conn;
r->server = conn->base_server;
- conn->keptalive = conn->keepalive == 1;
- conn->keepalive = 0;
-
r->user = NULL;
r->ap_auth_type = NULL;
@@ -571,7 +458,9 @@
r->notes = apr_table_make(r->pool, 5);
r->request_config = ap_create_request_config(r->pool);
- ap_run_create_request(r);
+ if (ap_run_create_request(r) != OK) {
+ return NULL;
+ }
r->per_dir_config = r->server->lookup_defaults;
r->sent_bodyct = 0; /* bytect isn't for body */
@@ -584,30 +473,10 @@
r->output_filters = conn->output_filters;
r->input_filters = conn->input_filters;
- apr_setsocketopt(conn->client_socket, APR_SO_TIMEOUT,
- (int)(conn->keptalive
- ? r->server->keep_alive_timeout * APR_USEC_PER_SEC
- : r->server->timeout * APR_USEC_PER_SEC));
-
ap_add_output_filter("BYTERANGE", NULL, r, r->connection);
ap_add_output_filter("CONTENT_LENGTH", NULL, r, r->connection);
ap_add_output_filter("HTTP_HEADER", NULL, r, r->connection);
- /* Get the request... */
- if (!read_request_line(r)) {
- if (r->status == HTTP_REQUEST_URI_TOO_LARGE) {
- ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, r,
- "request failed: URI too long");
- ap_send_error_response(r, 0);
- ap_run_log_transaction(r);
- return r;
- }
- return NULL;
- }
- if (r->connection->keptalive) {
- apr_setsocketopt(r->connection->client_socket, APR_SO_TIMEOUT,
- (int)(r->server->timeout * APR_USEC_PER_SEC));
- }
if (!r->assbackwards) {
get_mime_headers(r);
if (r->status != HTTP_REQUEST_TIME_OUT) {
@@ -645,8 +514,6 @@
/* we may have switched to another server */
r->per_dir_config = r->server->lookup_defaults;
-
- conn->keptalive = 0; /* We now have a request to play with */
if ((!r->hostname && (r->proto_num >= HTTP_VERSION(1,1))) ||
((r->proto_num == HTTP_VERSION(1,1)) &&
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Bill Stoddard <bi...@wstoddard.com>.
Thank you Roy...
> > Move the keepalives field out of the conn_rec and into an HTTP specific
> > connection record. This also moves some HTTP specific back out of the
> > core and into the HTTP module.
>
> -1. First, as I said at the hackathon, these variables are not specific
> to HTTP.
<snip>
>
> Third, I see no reason to make the Apache httpd code base generic to
> all protocols.
> If done at all, this work belongs in a different tree.
> I understand why it would be nice to have a multiprotocol routing core,
> but the current code base is nowhere near efficient enough to support
> such a change, certainly not without some justification from real users
> that need such a beast. We need to concentrate on getting it that way
> for at least SSL and HTTP.
I've been having these thoughts as well. Building a multiprotocol routing core is interesting but
for now our efforts should be focused on getting a servicable HTTP Server. We are diluting our
efforts spending time "adhoc'ing" the server to accomodate protocols other than HTTP.
>
> One of the things that needs to be kept in mind when building a
> multi-protocol server is that while many protocols carry the same
> elements, the applications that they support may have extremely
> different performance profiles.
> A server architecture has to be designed
> according to the application profile, not the syntax of the protocol that
> carries it.
I agree. FWIW, I attend an interesting presentation inside IBM over a year ago about porting the
Lotus Notes server to Linux. There were some serious performance issues that had to be handled in
designing the Notes server. Based on the performance requirements of that application, the Apache
2.0 framework would not come close to doing what is needed. Apache 2.0 cannot become all things to
all people. Let's focus our efforts on Apache 2.0 being an excellent HTTP server, like Apache 1.3.
Bill
Re: cvs commit: httpd-2.0/server protocol.c
Posted by fi...@ebuilt.com.
> OK, I was not at the HACKATON, but 'keepalive' is an HTTP
> specific protocol mechanism. If not, please refer me to some
> protocol that uses it?? :-))
keepalive as a name is used in many protocols, including TCP. The specific
function of those two variables is used by ANY server that places a limit
on requests per connection. It is not even remotely specific to HTTP.
The only Internet app protocol that I know of which would not use such a
limit is TELNET.
> With respect to moving HTTP specific variables out of the core
> I would follow my above statement. But as I understood
> keepalive is maybe HTTP protocol specific it is to much spread
> over Apache core code which makes the move difficult.
>
> Although, naming is not a real issue in my opinion.
> Would it not be an option to name it like 'keepconnection'??
> That means other protocols (and thus their module implementing it)
> that expect multiple requests over the same connection. However,
> this would extends the semantics a bit. Even though, you keep
> it as keepalive for HTTP.
As I said, the name can be changed, though I'll repeat that "Keep Alive"
is the common generic term for keeping a connection open for more than
one request. It is not HTTP specific. The only thing HTTP specific about
that code is the comments above the variable.
> > There are no limitations on requests per connection defined by HTTP.
> > It is a common tool to avoid denial-of-service (or, more accurately,
> > enforce fairness-of-service) at the application-layer.
>
> I am not sure what you mean here. Is "Limit" not designed for this??
> Or do you think of other limitation functionality??
>
> > Third, I see no reason to make the Apache httpd code base generic to
> > all protocols. If done at all, this work belongs in a different tree.
>
> Roy, but why are there now claims made Apache is capable of doing
> multiple protocols. I envision that protocol module would only
> make use of "ap_hook_process_connection" like mod_echo does.
> For the rest it does whatever it wants itself.
There are claims of it being multiprotocol because that was of the original
design goals that Robert Thau had for 2.0. By multiprotocol, he meant
HTTP and HTTPng (the original binary HTTP over SCP spec by Simon).
Multiprotocol does not mean every protocol under the sun.
> > I understand why it would be nice to have a multiprotocol routing core,
> > but the current code base is nowhere near efficient enough to support
> > such a change, certainly not without some justification from real users
> > that need such a beast. We need to concentrate on getting it that way
> > for at least SSL and HTTP.
>
> Would it not be possible that there are no users, since there is
> nothing (multiprotocol Apache) to use?? :-)))
No. A server is supposed to be simple. The only reason to have multiple
protocols within a single server is if you have multiple potential
protocols on the same port. That is why SSL, HTTP, HTTPng, SOAP, and
waka are all candidates for a multi-protocol httpd, whereas FTP and IMAP
and BXXP are not. That doesn't mean that someone can't use the Apache
software to create servers that handle those other protocols -- it only
means that the code doesn't belong in httpd.
I have no objections to starting a sandbox for a multiprotocol framework
that, once it proves to be better, can be adopted by the httpd project.
But it doesn't make any sense to do that in httpd-2.0, just as it didn't
make any sense to create APR within the main development tree.
....Roy
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> > There are no limitations on requests per connection defined by HTTP.
> > It is a common tool to avoid denial-of-service (or, more accurately,
> > enforce fairness-of-service) at the application-layer.
>
> I am not sure what you mean here. Is "Limit" not designed for this??
> Or do you think of other limitation functionality??
Nothing in the HTTP protocol spec puts a limit on the number of HTTP request/response pairs that can
flow over a connection. Well implemented HTTP Servers allow the sys admin to impose a limit on the
number of requests the server will server on a connection (e.g., MaxKeepAliveRequests). Why? To
keep a client (browser) from hogging all the resources at the server. In other words, to give all
clients 'fair' access to the server resources.
>
> > Third, I see no reason to make the Apache httpd code base generic to
> > all protocols. If done at all, this work belongs in a different tree.
>
> Roy, but why are there now claims made Apache is capable of doing
> multiple protocols.
That's hardly an argument to support multiprotocol routing...
> > I understand why it would be nice to have a multiprotocol routing core,
> > but the current code base is nowhere near efficient enough to support
> > such a change, certainly not without some justification from real users
> > that need such a beast. We need to concentrate on getting it that way
> > for at least SSL and HTTP.
>
> WOuld it not be possible that there are no users, since there is
> nothing (multiprotocol Apache) to use?? :-)))
Build it and they will come? Not a good business model IMHO, but it sometimes works in movies :-)
Seriously, have you any hard requirements from any application that is 1/100th as important as the
HTTP Server? Our primary "customers" are HTTP server users. Let's make them happy first and quite
trying to solve all the network server problems of the world, else we'll end up doing everything
half assed.
Bill
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Harrie Hazewinkel <ha...@covalent.net>.
Bill Stoddard wrote:
> >
>
> The protocol Lotus Notes uses is keepalive (yea, it is a proprietary protocol and may not count in
> this discussion).
Yes, that may. As a protocol guru I am probably not allowed to see the
protocol definition?? :-))
> Doesn't BXXP (is that what it is called now?) maintain persistent connections?
BEEP as it is now called. My understanding of BEEP is that it just
keeps the connection open like FTP when it is mapped upon TCP.
That is not really keep-alive as defined in HTTP.
> I
> know of more obscure proprietary protocols that flow multiple requests/response pairs over a
> persistent connection.
OK, keep-alive could indeed be more generic. I never really thought
of proprietary protocols.
Harrie
--
phone: +39-3474932300
http://www.lisanza.net/
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Bill Stoddard <bi...@wstoddard.com>.
> Roy,
>
> fielding@ebuilt.com wrote:
> >
> > > Move the keepalives field out of the conn_rec and into an HTTP specific
> > > connection record. This also moves some HTTP specific back out of the
> > > core and into the HTTP module.
> >
> > -1. First, as I said at the hackathon, these variables are not specific
> > to HTTP. They record and control limitations on the number of requests
> > per connection. You can change their names, if you want, but they must
> > be in the connection record for all protocols.
>
> OK, I was not at the HACKATON, but 'keepalive' is an HTTP
> specific protocol mechanism. If not, please refer me to some
> protocol that uses it?? :-))
>
The protocol Lotus Notes uses is keepalive (yea, it is a proprietary protocol and may not count in
this discussion). Doesn't BXXP (is that what it is called now?) maintain persistent connections? I
know of more obscure proprietary protocols that flow multiple requests/response pairs over a
persistent connection.
Bill
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Harrie Hazewinkel <ha...@covalent.net>.
Roy,
fielding@ebuilt.com wrote:
>
> > Move the keepalives field out of the conn_rec and into an HTTP specific
> > connection record. This also moves some HTTP specific back out of the
> > core and into the HTTP module.
>
> -1. First, as I said at the hackathon, these variables are not specific
> to HTTP. They record and control limitations on the number of requests
> per connection. You can change their names, if you want, but they must
> be in the connection record for all protocols.
OK, I was not at the HACKATON, but 'keepalive' is an HTTP
specific protocol mechanism. If not, please refer me to some
protocol that uses it?? :-))
With respect to moving HTTP specific variables out of the core
I would follow my above statement. But as I understood
keepalive is maybe HTTP protocol specific it is to much spread
over Apache core code which makes the move difficult.
Although, naming is not a real issue in my opinion.
Would it not be an option to name it like 'keepconnection'??
That means other protocols (and thus their module implementing it)
that expect multiple requests over the same connection. However,
this would extends the semantics a bit. Even though, you keep
it as keepalive for HTTP.
> There are no limitations on requests per connection defined by HTTP.
> It is a common tool to avoid denial-of-service (or, more accurately,
> enforce fairness-of-service) at the application-layer.
I am not sure what you mean here. Is "Limit" not designed for this??
Or do you think of other limitation functionality??
> Third, I see no reason to make the Apache httpd code base generic to
> all protocols. If done at all, this work belongs in a different tree.
Roy, but why are there now claims made Apache is capable of doing
multiple protocols. I envision that protocol module would only
make use of "ap_hook_process_connection" like mod_echo does.
For the rest it does whatever it wants itself.
> I understand why it would be nice to have a multiprotocol routing core,
> but the current code base is nowhere near efficient enough to support
> such a change, certainly not without some justification from real users
> that need such a beast. We need to concentrate on getting it that way
> for at least SSL and HTTP.
WOuld it not be possible that there are no users, since there is
nothing (multiprotocol Apache) to use?? :-)))
>
> One of the things that needs to be kept in mind when building a
> multi-protocol server is that while many protocols carry the same
> elements, the applications that they support may have extremely
> different performance profiles. A server architecture has to be designed
> according to the application profile, not the syntax of the protocol that
> carries it. Pools, for example, are not efficient enough to handle a
> long-lived stateful exchange -- a memory structure for that needs to
> be able to reclaim within the session. There are many other cases where
> the core will have to change radically in order to support those
> applications. Those changes should be proven separate from the 2.0
> server before they are inserted in a code base that doesn't even remotely
> need them.
I agree here that an implementation is in most cases design for a
perticular performance profile and protocol profile. With respect
to the multi-protocol document, Ryan and I did not envision that our
solution would fit all protocols ever existing/used. We envisioned
with a more commone framework fopr multiple protocols faster protocol
module development and more code re-use (for instance, making use of
the same authentication functions already implemented for HTTP).
>
> Finally, is it really necessary to do this while I am in Maui?
Enjoy Maui!! (Not to be mistaken with, now you are gone we will....
:-)))))
Cheers,
Harrie
--
phone: +39-3474932300
http://www.lisanza.net/
Re: cvs commit: httpd-2.0/server protocol.c
Posted by fi...@ebuilt.com.
> Move the keepalives field out of the conn_rec and into an HTTP specific
> connection record. This also moves some HTTP specific back out of the
> core and into the HTTP module.
-1. First, as I said at the hackathon, these variables are not specific
to HTTP. They record and control limitations on the number of requests
per connection. You can change their names, if you want, but they must
be in the connection record for all protocols.
There are no limitations on requests per connection defined by HTTP.
It is a common tool to avoid denial-of-service (or, more accurately,
enforce fairness-of-service) at the application-layer.
Second, you should never move code and change code in the same commit.
Third, I see no reason to make the Apache httpd code base generic to
all protocols. If done at all, this work belongs in a different tree.
I understand why it would be nice to have a multiprotocol routing core,
but the current code base is nowhere near efficient enough to support
such a change, certainly not without some justification from real users
that need such a beast. We need to concentrate on getting it that way
for at least SSL and HTTP.
One of the things that needs to be kept in mind when building a
multi-protocol server is that while many protocols carry the same
elements, the applications that they support may have extremely
different performance profiles. A server architecture has to be designed
according to the application profile, not the syntax of the protocol that
carries it. Pools, for example, are not efficient enough to handle a
long-lived stateful exchange -- a memory structure for that needs to
be able to reclaim within the session. There are many other cases where
the core will have to change radically in order to support those
applications. Those changes should be proven separate from the 2.0
server before they are inserted in a code base that doesn't even remotely
need them.
Finally, is it really necessary to do this while I am in Maui?
....Roy
Re: cvs commit: httpd-2.0/server protocol.c
Posted by fi...@ebuilt.com.
On Fri, Apr 20, 2001 at 04:47:15PM -0400, Bill Stoddard wrote:
> This patch avoids the segfault. Basically, the core_module hook needs to
> run first. Any problems with this?
Only that I already vetoed the patch that caused the problem in the first
place. Just back that one out. I'd have done it myself already but I
am reading mail remotely.
....Roy
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Fri, 20 Apr 2001 16:47:15 -0400, Bill Stoddard wrote:
>This patch avoids the segfault. Basically, the core_module hook needs to run first. Any problems
>with this?
I'm also seeing exactly the same segfault which your patch fixes. I've no
idea if it's the "right" fix though.
>Index: core.c
>===================================================================
>RCS file: /home/cvs/httpd-2.0/server/core.c,v
>retrieving revision 1.8
>diff -u -u -r1.8 core.c
>--- core.c 2001/04/11 23:37:16 1.8
>+++ core.c 2001/04/20 20:35:44
>@@ -3274,7 +3274,7 @@
> /* FIXME: I suspect we can eliminate the need for these - Ben */
> ap_hook_type_checker(do_nothing,NULL,NULL,APR_HOOK_REALLY_LAST);
> ap_hook_access_checker(do_nothing,NULL,NULL,APR_HOOK_REALLY_LAST);
>- ap_hook_create_request(core_create_req, NULL, NULL, APR_HOOK_MIDDLE);
>+ ap_hook_create_request(core_create_req, NULL, NULL, APR_HOOK_FIRST);
>
> /* register the core's insert_filter hook and register core-provided
> * filters
>
>
>> I am fairly sure this patch is at least a contributing factor to a seg fault I am trying to debug.
>> The seg fault, which happens on the first request to the server, is in ap_getline(). req_cfg is
>> NULL after the call to ap_get_module_config(). We blow up trying to reference req_cgg->bb. with a
>> NULL pointer. Here is the code snip...
>>
>> req_cfg = (core_request_config *)
>> ap_get_module_config(r->request_config, &core_module);
>> b = req_cfg->bb
>>
>> The problem is that ap_set_module_config() has not been called on core_module yet. Ryan, did this
>> code serve pages for you before you committed it?
>>
>> Bill
>>
>>
>>
>> > rbb 01/04/17 20:53:35
>> >
>> > Modified: include httpd.h
>> > modules/http config.m4 http_core.c http_protocol.c
>> > mod_core.h
>> > modules/loggers mod_log_config.c
>> > server protocol.c
>> > Log:
>> > Move the keepalives field out of the conn_rec and into an HTTP specific
>> > connection record. This also moves some HTTP specific back out of the
>> > core and into the HTTP module.
>> >
>> > Revision Changes Path
>> > 1.147 +0 -4 httpd-2.0/include/httpd.h
>> >
>>
>>
>
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Bill Stoddard <bi...@wstoddard.com>.
This patch avoids the segfault. Basically, the core_module hook needs to run first. Any problems
with this?
Index: core.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.8
diff -u -u -r1.8 core.c
--- core.c 2001/04/11 23:37:16 1.8
+++ core.c 2001/04/20 20:35:44
@@ -3274,7 +3274,7 @@
/* FIXME: I suspect we can eliminate the need for these - Ben */
ap_hook_type_checker(do_nothing,NULL,NULL,APR_HOOK_REALLY_LAST);
ap_hook_access_checker(do_nothing,NULL,NULL,APR_HOOK_REALLY_LAST);
- ap_hook_create_request(core_create_req, NULL, NULL, APR_HOOK_MIDDLE);
+ ap_hook_create_request(core_create_req, NULL, NULL, APR_HOOK_FIRST);
/* register the core's insert_filter hook and register core-provided
* filters
> I am fairly sure this patch is at least a contributing factor to a seg fault I am trying to debug.
> The seg fault, which happens on the first request to the server, is in ap_getline(). req_cfg is
> NULL after the call to ap_get_module_config(). We blow up trying to reference req_cgg->bb. with a
> NULL pointer. Here is the code snip...
>
> req_cfg = (core_request_config *)
> ap_get_module_config(r->request_config, &core_module);
> b = req_cfg->bb
>
> The problem is that ap_set_module_config() has not been called on core_module yet. Ryan, did this
> code serve pages for you before you committed it?
>
> Bill
>
>
>
> > rbb 01/04/17 20:53:35
> >
> > Modified: include httpd.h
> > modules/http config.m4 http_core.c http_protocol.c
> > mod_core.h
> > modules/loggers mod_log_config.c
> > server protocol.c
> > Log:
> > Move the keepalives field out of the conn_rec and into an HTTP specific
> > connection record. This also moves some HTTP specific back out of the
> > core and into the HTTP module.
> >
> > Revision Changes Path
> > 1.147 +0 -4 httpd-2.0/include/httpd.h
> >
>
>
Re: cvs commit: httpd-2.0/server protocol.c
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
Bill, Rbb...
we never decided the canonical order of operations between core and http. See
os/win32/modules.c for our 'current' ordering.
I don't know precisely your issues (I'm buried in other things as you are both
aware) but keep in mind all of the http/core protocol stuff will become rather messy
unless we decide what we load when, mpm's, core and http. If we ultimately have an
http-less server (ugh!) consider the core and mpm need to load first, which is which
I don't really know.
Bill
----- Original Message -----
From: <rb...@covalent.net>
To: <ne...@apache.org>
Sent: Friday, April 20, 2001 5:21 PM
Subject: Re: cvs commit: httpd-2.0/server protocol.c
> On Fri, 20 Apr 2001, Bill Stoddard wrote:
>
> > I am fairly sure this patch is at least a contributing factor to a seg fault I am trying to debug.
> > The seg fault, which happens on the first request to the server, is in ap_getline(). req_cfg is
> > NULL after the call to ap_get_module_config(). We blow up trying to reference req_cgg->bb. with a
> > NULL pointer. Here is the code snip...
> >
> > req_cfg = (core_request_config *)
> > ap_get_module_config(r->request_config, &core_module);
> > b = req_cfg->bb
> >
> > The problem is that ap_set_module_config() has not been called on core_module yet. Ryan, did this
> > code serve pages for you before you committed it?
>
> This code has served static pages and SSI pages for me.
>
> I will try to look at what you are seeing later today.
>
> Ryan
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
>
>
Re: cvs commit: httpd-2.0/server protocol.c
Posted by rb...@covalent.net.
On Fri, 20 Apr 2001, Bill Stoddard wrote:
> I am fairly sure this patch is at least a contributing factor to a seg fault I am trying to debug.
> The seg fault, which happens on the first request to the server, is in ap_getline(). req_cfg is
> NULL after the call to ap_get_module_config(). We blow up trying to reference req_cgg->bb. with a
> NULL pointer. Here is the code snip...
>
> req_cfg = (core_request_config *)
> ap_get_module_config(r->request_config, &core_module);
> b = req_cfg->bb
>
> The problem is that ap_set_module_config() has not been called on core_module yet. Ryan, did this
> code serve pages for you before you committed it?
This code has served static pages and SSI pages for me.
I will try to look at what you are seeing later today.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server protocol.c
Posted by Bill Stoddard <bi...@wstoddard.com>.
I am fairly sure this patch is at least a contributing factor to a seg fault I am trying to debug.
The seg fault, which happens on the first request to the server, is in ap_getline(). req_cfg is
NULL after the call to ap_get_module_config(). We blow up trying to reference req_cgg->bb. with a
NULL pointer. Here is the code snip...
req_cfg = (core_request_config *)
ap_get_module_config(r->request_config, &core_module);
b = req_cfg->bb
The problem is that ap_set_module_config() has not been called on core_module yet. Ryan, did this
code serve pages for you before you committed it?
Bill
> rbb 01/04/17 20:53:35
>
> Modified: include httpd.h
> modules/http config.m4 http_core.c http_protocol.c
> mod_core.h
> modules/loggers mod_log_config.c
> server protocol.c
> Log:
> Move the keepalives field out of the conn_rec and into an HTTP specific
> connection record. This also moves some HTTP specific back out of the
> core and into the HTTP module.
>
> Revision Changes Path
> 1.147 +0 -4 httpd-2.0/include/httpd.h
>