Re: [Win32] Apache 2.0.40-dev error compiling latest snapshots
On Sat, 2002-07-06 at 23:31, Sebastian Bergmann wrote: > Brian Pane wrote: > > It may be unsafe to cast to a long when the arg is a "%qd". How > > about this: > > Compiles as well :) Thanks, I've just committed the change. --Brian
Re: [Win32] Apache 2.0.40-dev error compiling latest snapshots
Brian Pane wrote: > It may be unsafe to cast to a long when the arg is a "%qd". How > about this: Compiles as well :) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Re: [Win32] Apache 2.0.40-dev error compiling latest snapshots
On Sat, 2002-07-06 at 23:07, Sebastian Bergmann wrote:
> Juergen Heckel wrote:
> > Replacing the ab.c with an older version solves this little problem.
>
> Index: support/ab.c
> ===
> RCS file: /home/cvspublic/httpd-2.0/support/ab.c,v
> retrieving revision 1.106
> diff -u -r1.106 ab.c
> --- support/ab.c 4 Jul 2002 22:56:51 - 1.106
> +++ support/ab.c 7 Jul 2002 06:06:10 -
> @@ -1101,8 +1101,8 @@
> trstring, tdstring, tdstring, concurrency);
> printf("Time taken for tests:"
> "%qd.%03qd seconds\n",
> -trstring, tdstring, tdstring, (long long)apr_time_sec(timetaken),
> - (long long)apr_time_usec(timetaken));
> +trstring, tdstring, tdstring, (long)apr_time_sec(timetaken),
> + (long)apr_time_usec(timetaken));
> printf("Complete requests:"
> "%ld\n",
> trstring, tdstring, tdstring, done);
It may be unsafe to cast to a long when the arg is a "%qd". How
about this:
Index: support/ab.c
===
RCS file: /home/cvs/httpd-2.0/support/ab.c,v
retrieving revision 1.106
diff -u -r1.106 ab.c
--- support/ab.c4 Jul 2002 22:56:51 - 1.106
+++ support/ab.c7 Jul 2002 06:16:55 -
@@ -1100,9 +1100,9 @@
"%d\n",
trstring, tdstring, tdstring, concurrency);
printf("Time taken for tests:"
- "%qd.%03qd seconds\n",
- trstring, tdstring, tdstring, (long long)apr_time_sec(timetaken),
- (long long)apr_time_usec(timetaken));
+ "%qd.%03ld seconds\n",
+ trstring, tdstring, tdstring, apr_time_sec(timetaken),
+ (long)apr_time_usec(timetaken));
printf("Complete requests:"
"%ld\n",
trstring, tdstring, tdstring, done);
Re: [Win32] Apache 2.0.40-dev error compiling latest snapshots
Juergen Heckel wrote:
> Replacing the ab.c with an older version solves this little problem.
Index: support/ab.c
===
RCS file: /home/cvspublic/httpd-2.0/support/ab.c,v
retrieving revision 1.106
diff -u -r1.106 ab.c
--- support/ab.c4 Jul 2002 22:56:51 - 1.106
+++ support/ab.c7 Jul 2002 06:06:10 -
@@ -1101,8 +1101,8 @@
trstring, tdstring, tdstring, concurrency);
printf("Time taken for tests:"
"%qd.%03qd seconds\n",
- trstring, tdstring, tdstring, (long long)apr_time_sec(timetaken),
- (long long)apr_time_usec(timetaken));
+ trstring, tdstring, tdstring, (long)apr_time_sec(timetaken),
+ (long)apr_time_usec(timetaken));
printf("Complete requests:"
"%ld\n",
trstring, tdstring, tdstring, done);
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
[Win32] Apache 2.0.40-dev error compiling latest snapshots
Hi, since 3 days I cannot compile the latest snapshots without an error: ab.c F:\Projects\MSVC\httpd-2.0\support\ab.c(831) : warning C4244: '=' : conversion from 'double ' to 'float ', possible loss of data F:\Projects\MSVC\httpd-2.0\support\ab.c(1104) : error C2632: 'long' followed by 'long' is illegal F:\Projects\MSVC\httpd-2.0\support\ab.c(1105) : error C2632: 'long' followed by 'long' is illegal Error executing cl.exe. Apache.exe - 2 error(s), 3 warning(s) Replacing the ab.c with an older version solves this little problem. Juergen
[PATCH] Making the protocol check runtime
This is not the complete patch, but implements the logic of the
protocol check... This also avoids the use of '%n' for sscanf and
instead uses a nice little trick.
Comments? If this looks good, I'll add the remaining bits (like the
directive) and commit.
Index: src/main/http_protocol.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
retrieving revision 1.322
diff -u -r1.322 http_protocol.c
--- src/main/http_protocol.c26 Jun 2002 18:34:00 - 1.322
+++ src/main/http_protocol.c6 Jul 2002 20:55:42 -
@@ -991,7 +991,9 @@
const char *uri;
conn_rec *conn = r->connection;
unsigned int major = 1, minor = 0; /* Assume HTTP/1.0 if non-"HTTP" protocol */
-int len, n = 0;
+int len = 0;
+int valid_protocol = 1;
+char *kruft;
/* Read past empty lines until we get a real request line,
* a read error, the connection closes (EOF), or we timeout.
@@ -1053,26 +1055,41 @@
r->assbackwards = (ll[0] == '\0');
r->protocol = ap_pstrdup(r->pool, ll[0] ? ll : "HTTP/0.9");
-if (2 == sscanf(r->protocol, "HTTP/%u.%u%n", &major, &minor, &n)
- && minor < HTTP_VERSION(1,0))/* don't allow HTTP/0.1000 */
- r->proto_num = HTTP_VERSION(major, minor);
+/* Avoid sscanf in the common case */
+if (strlen(r->protocol) == 8
+&& r->protocol[0] == 'H' && r->protocol[1] == 'T'
+ && r->protocol[2] == 'T' && r->protocol[3] == 'P'
+&& r->protocol[4] == '/' && ap_isdigit(r->protocol[5])
+ && r->protocol[6] == '.' && ap_isdigit(r->protocol[7])) {
+r->proto_num = HTTP_VERSION(r->protocol[5] - '0', r->protocol[7] - '0');
+}
else {
- r->proto_num = HTTP_VERSION(1,0);
- n = 0;
+ kruft = ap_palloc(r->pool, strlen(r->protocol)+1);
+ if (2 == sscanf(r->protocol, "HTTP/%u.%u%s", &major, &minor, kruft)
+ && 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);
+ valid_protocol = 0;
+ }
}
/* Check for a valid protocol, and disallow everything but whitespace
- * after the protocol string */
-while (ap_isspace(r->protocol[n]))
-++n;
-if (r->protocol[n] != '\0') {
-r->status= HTTP_BAD_REQUEST;
-r->proto_num = HTTP_VERSION(1,0);
-r->protocol = ap_pstrdup(r->pool, "HTTP/1.0");
-ap_table_setn(r->notes, "error-notes",
- "The request line contained invalid characters "
- "following the protocol string.\n");
-return 0;
+ * after the protocol string. A protocol string of nothing but
+ * whitespace is considered valid */
+if (ap_protocol_req_check && !valid_protocol) {
+int n = 0;
+ while (ap_isspace(r->protocol[n]))
+ ++n;
+ if (r->protocol[n] != '\0') {
+ r->status= HTTP_BAD_REQUEST;
+ r->proto_num = HTTP_VERSION(1,0);
+ r->protocol = ap_pstrdup(r->pool, "HTTP/1.0");
+ ap_table_setn(r->notes, "error-notes",
+ "The request line contained invalid characters "
+ "following the protocol string.\n");
+ return 0;
+ }
}
return 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: Removing C-L filter when C-L is known was Re: conserving filedescriptors vs. ap_save_brigade()
Justin Erenkrantz wrote:
>On Sat, Jul 06, 2002 at 12:09:40PM -0700, Ryan Bloom wrote:
>
>
>>Pay attention to what that message says please. It says "The filter
>>should always be in the stack, and it should always collect
>>information." It doesn't say "The filter should always be touching the
>>C-L for the response." We use the data collected by the c-L filter in
>>other places, so we should always try to compute the C-L in the filter.
>>However, we should NEVER buffer unless we absolutely have to.
>>
>>
>
>What data is it collecting? r->bytes_sent? We already know what
>that value will be as it will be identical to the C-L.
>
>To make it concrete as to what I have been suggesting in
>ap_content_length_filter:
>
>if (!ctx) { /* first time through */
>char *c;
>c = apr_table_get(r->headers_out, "Content-Length");
>
This won't help us much: in all the cases where the ap_save_brigade()
in the C-L filter is a performance problem (e.g., the pipe and SSI
examples), we're not going to have a C-L in r->headers_out.
And this change will slow down the server, by adding another call to
apr_table_get(), which we already know is a performance problem.
--Brian
Removing C-L filter when C-L is known was Re: conserving file descriptors vs. ap_save_brigade()
On Sat, Jul 06, 2002 at 12:09:40PM -0700, Ryan Bloom wrote:
> Pay attention to what that message says please. It says "The filter
> should always be in the stack, and it should always collect
> information." It doesn't say "The filter should always be touching the
> C-L for the response." We use the data collected by the c-L filter in
> other places, so we should always try to compute the C-L in the filter.
> However, we should NEVER buffer unless we absolutely have to.
What data is it collecting? r->bytes_sent? We already know what
that value will be as it will be identical to the C-L.
To make it concrete as to what I have been suggesting in
ap_content_length_filter:
if (!ctx) { /* first time through */
char *c;
c = apr_table_get(r->headers_out, "Content-Length");
if (c) { /* Known content length. */
/* Can we rely on r->clength being valid? Perhaps because of
* ap_set_content_length's implementation. If not, we'd have
* to convert the c value to an off_t.
*/
r->bytes_sent += r->clength;
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, b);
}
f->ctx = ctx = apr_pcalloc(r->pool, sizeof(struct content_length_ctx));
...rest of ap_content_length_filter unchanged...
Does this make it any clearer? The side effect r->bytes_sent is
still maintained and the common case becomes a lot faster and we
don't bother to read any of the buckets. -- justin
[PATCH] apr-util renames
This patch kinda goes with the cvs commit I just did on apr-util.
According to my testing httpd still compiles without it, but... :)
-Thom
Index: modules/dav/main/util.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/dav/main/util.c,v
retrieving revision 1.39
diff -u -r1.39 util.c
--- modules/dav/main/util.c 23 Jun 2002 06:42:13 - 1.39
+++ modules/dav/main/util.c 6 Jul 2002 19:06:18 -
@@ -247,7 +247,7 @@
/* insert a port if the URI did not contain one */
if (comp.port == 0)
-comp.port = apr_uri_default_port_for_scheme(comp.scheme);
+comp.port = apr_uri_port_of_scheme(comp.scheme);
/* now, verify that the URI uses the same scheme as the current.
request. the port must match our port.
Index: modules/proxy/mod_proxy.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/proxy/mod_proxy.c,v
retrieving revision 1.86
diff -u -r1.86 mod_proxy.c
--- modules/proxy/mod_proxy.c 23 Jun 2002 06:06:25 - 1.86
+++ modules/proxy/mod_proxy.c 6 Jul 2002 19:06:21 -
@@ -604,7 +604,7 @@
ap_str_tolower(p + 3); /* lowercase hostname */
if (port == -1) {
-port = apr_uri_default_port_for_scheme(scheme);
+port = apr_uri_port_of_scheme(scheme);
}
new = apr_array_push(conf->proxies);
Index: modules/proxy/proxy_ftp.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/proxy/proxy_ftp.c,v
retrieving revision 1.124
diff -u -r1.124 proxy_ftp.c
--- modules/proxy/proxy_ftp.c 28 Jun 2002 08:40:24 - 1.124
+++ modules/proxy/proxy_ftp.c 6 Jul 2002 19:06:24 -
@@ -188,7 +188,7 @@
else {
return DECLINED;
}
-def_port = apr_uri_default_port_for_scheme("ftp");
+def_port = apr_uri_port_of_scheme("ftp");
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
"proxy: FTP: canonicalising URL %s", url);
@@ -851,7 +851,7 @@
connectname = r->parsed_uri.hostname;
connectport = (r->parsed_uri.port != 0)
? r->parsed_uri.port
-: apr_uri_default_port_for_scheme("ftp");
+: apr_uri_port_of_scheme("ftp");
path = apr_pstrdup(p, r->parsed_uri.path);
path = (path != NULL && path[0] != '\0') ? &path[1] : "";
Index: modules/proxy/proxy_http.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/proxy/proxy_http.c,v
retrieving revision 1.155
diff -u -r1.155 proxy_http.c
--- modules/proxy/proxy_http.c 26 Jun 2002 19:45:07 - 1.155
+++ modules/proxy/proxy_http.c 6 Jul 2002 19:06:26 -
@@ -92,7 +92,7 @@
const char *scheme;
apr_port_t port, def_port;
-/* ap_default_port_for_scheme() */
+/* ap_port_of_scheme() */
if (strncasecmp(url, "http:", 5) == 0) {
url += 5;
scheme = "http";
@@ -104,7 +104,7 @@
else {
return DECLINED;
}
-def_port = apr_uri_default_port_for_scheme(scheme);
+def_port = apr_uri_port_of_scheme(scheme);
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
"proxy: HTTP: canonicalising URL %s", url);
@@ -215,7 +215,7 @@
NULL));
}
if (!uri->port) {
-uri->port = apr_uri_default_port_for_scheme(uri->scheme);
+uri->port = apr_uri_port_of_scheme(uri->scheme);
}
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
Index: server/config.c
===
RCS file: /home/cvspublic/httpd-2.0/server/config.c,v
retrieving revision 1.153
diff -u -r1.153 config.c
--- server/config.c 28 Jun 2002 08:40:25 - 1.153
+++ server/config.c 6 Jul 2002 19:06:29 -
@@ -144,7 +144,7 @@
ap_LINK_post_config_t *pHook;
if (!_hooks.link_post_config) {
-_hooks.link_post_config = apr_array_make(apr_global_hook_pool, 1,
+_hooks.link_post_config = apr_array_make(apr_hook_global_pool, 1,
sizeof(ap_LINK_post_config_t));
apr_hook_sort_register("post_config", &_hooks.link_post_config);
}
@@ -154,10 +154,10 @@
pHook->aszPredecessors = aszPre;
pHook->aszSuccessors = aszSucc;
pHook->nOrder = nOrder;
-pHook->szName = apr_current_hooking_module;
+pHook->szName = apr_hook_debug_current;
-if (apr_debug_module_hooks)
-apr_show_hook("post_config", aszPre, aszSucc);
+if (apr_hook_debug_enabled)
+apr_hook_debug_show("post_config", aszPre, aszSucc);
}
AP_DECLARE(apr_array_header_t *) ap_hook_get_post_config(void) {
@@ -431,10 +431,10 @@
if (m->register_hooks) {
if (getenv("SHOW_HOOKS")) {
printf("Registering hooks for %s\n", m->name);
-apr_debug_module_hooks = 1;
+
RE: conserving file descriptors vs. ap_save_brigade()
On Sat, 2002-07-06 at 12:09, Ryan Bloom wrote: > > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > > > On Sat, Jul 06, 2002 at 08:25:18AM -0700, Ryan Bloom wrote: > > > > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > > > Of course, in the common case of a static file with no filters, we > > > > already know the content-length (default handler sets it). > > > > > > > > IIRC, I've brought up skipping the C-L filter when we already know > > > > the C-L (as defined by r->headers_out), but that was not met with > > > > approval. > > > > > > Who didn't approve that? I was under the impression that we did > skip > > > the C-L filter if we already had a C-L, and it was the filters > > > responsibility to remove the C-L if it was changing it. > > > > <[EMAIL PROTECTED]> > > > > I don't know who might have said that. =) -- Justin > > Pay attention to what that message says please. It says "The filter > should always be in the stack, and it should always collect > information." It doesn't say "The filter should always be touching the > C-L for the response." We use the data collected by the c-L filter in > other places, so we should always try to compute the C-L in the filter. > However, we should NEVER buffer unless we absolutely have to. The C-L filter is actually too early to be computing r->bytes_sent. The problem is pipe buckets. If the output brigade contains a pipe bucket, or anything else for which the length is not yet known, the C-L filter does an apr_bucket_read(). That's bad. We should leave file and pipe buckets unread until the core output filter, so that we don't lose the opportunity to send them using sendfile. Is there anything that happens after the C-L filter but before the core output filter that requires a final value for r->bytes_sent? --Brian
RE: PATH_INFO in A2?
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > On Sat, Jul 06, 2002 at 03:11:20PM -0400, [EMAIL PROTECTED] wrote: > > We just added a new function for all input filters to allow this to be > > done (Justin referenced it in his reply). However, that function > doesn't > > solve the problem, because there should be an ap_filter_is_dynamic(r) > that > > hides the implementation details for all filters. > > I don't believe that mod_include would want AcceptPathInfo on. > Only PHP would. So, I don't know what ap_filter_is_dynamic() would > buy here (other than setting r->no_local_copy to 1). -- Justin ap_filter_is_dynamic wouldn't replace the init function, it would be a simple function that the init functions could call to easily setup the filters. Ryan
RE: conserving file descriptors vs. ap_save_brigade()
On Sat, 2002-07-06 at 12:09, Ryan Bloom wrote: > > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > > > On Sat, Jul 06, 2002 at 08:25:18AM -0700, Ryan Bloom wrote: > > > > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > > > Of course, in the common case of a static file with no filters, we > > > > already know the content-length (default handler sets it). > > > > > > > > IIRC, I've brought up skipping the C-L filter when we already know > > > > the C-L (as defined by r->headers_out), but that was not met with > > > > approval. > > > > > > Who didn't approve that? I was under the impression that we did > skip > > > the C-L filter if we already had a C-L, and it was the filters > > > responsibility to remove the C-L if it was changing it. > > > > <[EMAIL PROTECTED]> > > > > I don't know who might have said that. =) -- Justin > > Pay attention to what that message says please. It says "The filter > should always be in the stack, and it should always collect > information." It doesn't say "The filter should always be touching the > C-L for the response." We use the data collected by the c-L filter in > other places, so we should always try to compute the C-L in the filter. > However, we should NEVER buffer unless we absolutely have to. Agreed. But what are the circumstances in which we absolutely have to buffer? I suppose keepalive requests for clients that don't support chunked encoding are the canonical absolutely-must-buffer case. But even there, I'd rather force a "Connection: close" in cases where the buffering is going to cause performance problems or cause us to run out of file descriptors. --Brian
Re: PATH_INFO in A2?
> On Sat, Jul 06, 2002 at 03:11:20PM -0400, [EMAIL PROTECTED] wrote: > > We just added a new function for all input filters to allow this to be > > done (Justin referenced it in his reply). However, that function doesn't > > solve the problem, because there should be an ap_filter_is_dynamic(r) that > > hides the implementation details for all filters. > > I don't believe that mod_include would want AcceptPathInfo on. > Only PHP would. So, I don't know what ap_filter_is_dynamic() would > buy here (other than setting r->no_local_copy to 1). -- justin Why wouldn't mod_include want AcceptPathInfo to be on? I am sure there are .shtml files out there that are written with the assumption that PATH_INFO is set correctly. -Rasmus
Re: PATH_INFO in A2?
On Sat, Jul 06, 2002 at 03:11:20PM -0400, [EMAIL PROTECTED] wrote: > We just added a new function for all input filters to allow this to be > done (Justin referenced it in his reply). However, that function doesn't > solve the problem, because there should be an ap_filter_is_dynamic(r) that > hides the implementation details for all filters. I don't believe that mod_include would want AcceptPathInfo on. Only PHP would. So, I don't know what ap_filter_is_dynamic() would buy here (other than setting r->no_local_copy to 1). -- justin
RE: PATH_INFO in A2?
On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: > > > What is a dynamic page if not a PHP page? > > > > Like I said, Apache doesn't know if a file on disk is meant for PHP or > > not. The best way to fix this would be for mod_php to set the value if > > the filter is added for the request. > > > > I agree, it would be cool if Apache could set this correctly based on > > the filters that have been added for the request. > > Seems like there should be an API call where a filter can specify whether > it is a dynamic one or not as opposed to specifically flipping the > acceptpathinfo bit. We just added a new function for all input filters to allow this to be done (Justin referenced it in his reply). However, that function doesn't solve the problem, because there should be an ap_filter_is_dynamic(r) that hides the implementation details for all filters. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
RE: conserving file descriptors vs. ap_save_brigade()
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > On Sat, Jul 06, 2002 at 08:25:18AM -0700, Ryan Bloom wrote: > > > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > > Of course, in the common case of a static file with no filters, we > > > already know the content-length (default handler sets it). > > > > > > IIRC, I've brought up skipping the C-L filter when we already know > > > the C-L (as defined by r->headers_out), but that was not met with > > > approval. > > > > Who didn't approve that? I was under the impression that we did skip > > the C-L filter if we already had a C-L, and it was the filters > > responsibility to remove the C-L if it was changing it. > > <[EMAIL PROTECTED]> > > I don't know who might have said that. =) -- Justin Pay attention to what that message says please. It says "The filter should always be in the stack, and it should always collect information." It doesn't say "The filter should always be touching the C-L for the response." We use the data collected by the c-L filter in other places, so we should always try to compute the C-L in the filter. However, we should NEVER buffer unless we absolutely have to. Ryan
Re: PATH_INFO in A2?
On Sat, Jul 06, 2002 at 10:02:24AM -0700, Rasmus Lerdorf wrote: > > > What is a dynamic page if not a PHP page? > > > > Like I said, Apache doesn't know if a file on disk is meant for PHP or > > not. The best way to fix this would be for mod_php to set the value if > > the filter is added for the request. > > > > I agree, it would be cool if Apache could set this correctly based on > > the filters that have been added for the request. > > Seems like there should be an API call where a filter can specify whether > it is a dynamic one or not as opposed to specifically flipping the > acceptpathinfo bit. Sounds like PHP needs to implement the filter_init function. It is exactly for this situation. -- justin
Re: conserving file descriptors vs. ap_save_brigade()
On Sat, Jul 06, 2002 at 08:25:18AM -0700, Ryan Bloom wrote: > > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > Of course, in the common case of a static file with no filters, we > > already know the content-length (default handler sets it). > > > > IIRC, I've brought up skipping the C-L filter when we already know > > the C-L (as defined by r->headers_out), but that was not met with > > approval. > > Who didn't approve that? I was under the impression that we did skip > the C-L filter if we already had a C-L, and it was the filters > responsibility to remove the C-L if it was changing it. <[EMAIL PROTECTED]> I don't know who might have said that. =) -- justin
RE: PATH_INFO in A2?
> > What is a dynamic page if not a PHP page? > > Like I said, Apache doesn't know if a file on disk is meant for PHP or > not. The best way to fix this would be for mod_php to set the value if > the filter is added for the request. > > I agree, it would be cool if Apache could set this correctly based on > the filters that have been added for the request. Seems like there should be an API call where a filter can specify whether it is a dynamic one or not as opposed to specifically flipping the acceptpathinfo bit. -Rasmus
RE: PATH_INFO in A2?
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] > > > > > Make sure you have AcceptPathInfo On > > > > > > Argh! Why the heck is that off by default? > > > > It's on by default for dynamic pages, but there is no way that Apache > > can tell that a page is going to be served by PHP, so it is off for what > > Apache thinks are static pages. > > What is a dynamic page if not a PHP page? Like I said, Apache doesn't know if a file on disk is meant for PHP or not. The best way to fix this would be for mod_php to set the value if the filter is added for the request. I agree, it would be cool if Apache could set this correctly based on the filters that have been added for the request. Ryan
HostnamesLookup in 2.0.39 not working?
Hi, may it be correct, that there ist no difference between setting HostnameLookups to 'On' or 'Off' in httpd 2.0.39 on Linux ? I'm not sure, but both settings just bring the IP instead of anything else in the log. Thank you for looking it over. kind regards Heinrich -- http://www.xmlBlaster.org
Re: PATH_INFO in A2?
Dale Ghent wrote: > Make sure you have AcceptPathInfo On Now it works, thanks. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
RE: PATH_INFO in A2?
> > > Make sure you have AcceptPathInfo On > > > > Argh! Why the heck is that off by default? > > It's on by default for dynamic pages, but there is no way that Apache > can tell that a page is going to be served by PHP, so it is off for what > Apache thinks are static pages. What is a dynamic page if not a PHP page? -Rasmus
RE: PATH_INFO in A2?
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] > > On Sat, 6 Jul 2002, Dale Ghent wrote: > > > On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: > > > > | 2.0.40-dev built on June 23rd > > > > Make sure you have AcceptPathInfo On > > Argh! Why the heck is that off by default? It's on by default for dynamic pages, but there is no way that Apache can tell that a page is going to be served by PHP, so it is off for what Apache thinks are static pages. Ryan
Re: PATH_INFO in A2?
On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: | On Sat, 6 Jul 2002, Dale Ghent wrote: | | > On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: | > | > | 2.0.40-dev built on June 23rd | > | > Make sure you have AcceptPathInfo On | | Argh! Why the heck is that off by default? Dunno. I ran into this same problem a while back when I made the switch from AP1.3 to AP2. It has always seemed like a regression to me (especially when there's no mention on the change in any of the AP2 upgrade docs. There was no AcceptPathInfo directive in 1.3. It got added in AP2 with a default of Off (obviously). I don't know the original meaning of this. I guess having a switch for this is cool... but it's default shouldnt stray from what has been expected all the long. /dale
Re: PATH_INFO in A2?
On Sat, 6 Jul 2002, Dale Ghent wrote: > On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: > > | 2.0.40-dev built on June 23rd > > Make sure you have AcceptPathInfo On Argh! Why the heck is that off by default? -Rasmus
RE: conserving file descriptors vs. ap_save_brigade()
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > On Sat, Jul 06, 2002 at 01:03:42AM -0700, Brian Pane wrote: > > As it's currently implemented, the C-L filter is trying to compute > > the C-L on everything by default. It only gives up in a few cases: > > Of course, in the common case of a static file with no filters, we > already know the content-length (default handler sets it). > > IIRC, I've brought up skipping the C-L filter when we already know > the C-L (as defined by r->headers_out), but that was not met with > approval. Who didn't approve that? I was under the impression that we did skip the C-L filter if we already had a C-L, and it was the filters responsibility to remove the C-L if it was changing it. Ryan
Re: PATH_INFO in A2?
On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: | 2.0.40-dev built on June 23rd Make sure you have AcceptPathInfo On /dale
Re: PATH_INFO in A2?
2.0.40-dev built on June 23rd On Sat, 6 Jul 2002, Dale Ghent wrote: > On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: > > | The requested URL /index.php/foo was not found on this server. > | > | In Apache1 /index.php would still get passed to PHP and /foo would end up > | in the PATH_INFO server var. > > What AP2 code are you using? I'm running .40-dev with a CVS update as of > last afternoon (right after Bpane's apr_table mods) and PHP 4.2.1 (with > the set-cookie fix)... everything is fine for me on a site that reqires > PATH_INFO ( http://playadelfuego.org/ ) > > /dale >
Re: PATH_INFO in A2?
On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: | The requested URL /index.php/foo was not found on this server. | | In Apache1 /index.php would still get passed to PHP and /foo would end up | in the PATH_INFO server var. What AP2 code are you using? I'm running .40-dev with a CVS update as of last afternoon (right after Bpane's apr_table mods) and PHP 4.2.1 (with the set-cookie fix)... everything is fine for me on a site that reqires PATH_INFO ( http://playadelfuego.org/ ) /dale
PATH_INFO in A2?
With this config: LoadModule php4_modulemodules/libphp4.so AddType application/x-httpd-php .php http://localhost/index.php works fine and parser PHP pages without problems. (using prefork - but it shouldn't matter) However: http://localhost/index.php/foo Gives a 404 and says: The requested URL /index.php/foo was not found on this server. In Apache1 /index.php would still get passed to PHP and /foo would end up in the PATH_INFO server var. -Rasmus
Re: conserving file descriptors vs. ap_save_brigade()
On Sat, Jul 06, 2002 at 01:03:42AM -0700, Brian Pane wrote: > As it's currently implemented, the C-L filter is trying to compute > the C-L on everything by default. It only gives up in a few cases: Of course, in the common case of a static file with no filters, we already know the content-length (default handler sets it). IIRC, I've brought up skipping the C-L filter when we already know the C-L (as defined by r->headers_out), but that was not met with approval. Perhaps, we should reconsider this? -- justin
RE: conserving file descriptors vs. ap_save_brigade()
On Wed, 2002-07-03 at 20:07, Ryan Bloom wrote: > > From: Brian Pane [mailto:[EMAIL PROTECTED]] > > > > On Wed, 2002-07-03 at 15:26, Ryan Bloom wrote: > > > How big a problem is this really? Most of the time, the > content-length > > > filter isn't supposed to actually buffer the brigade. It should > only be > > > doing the buffering if we are doing a keepalive request and we can't > do > > > chunking. > > > > I'm seeing the buffering in non-keepalive tests, though. > > Then we have a bug. The C-L filter should only be trying to compute the > C-L if we MUST have one on the response, and we don't have to have one > in the non-keepalive case. As it's currently implemented, the C-L filter is trying to compute the C-L on everything by default. It only gives up in a few cases: * More than 32KB of output buffered, and either * A flush bucket in the brigade * EAGAIN when trying to read from a pipe bucket And in all of these cases, it it also requires either a non-keepalive request or a client that supports chunked encoding in order to give up on computing the length. So if we have a long stream of small file buckets from an SSI request, we'll never hit any of the conditions that cause the C-L filter to give up trying to compute the C-L. --Brian
