mod_include bug(s)?
I've spent the entire evening chasing some wacky mod_include bugs that
surfaced as I was doing final testing on the bucket API patch. At first I
assumed they were my fault, but upon further investigation I think the
fact that they haven't surfaced until now is a coincidence. There are two
problems that I can see -- the if6.shtml and if7.shtml files I committed
to httpd-test last week to check for the mod_include 1.3 bug has turned up
quasi-related problems in mod_include 2.0 as well.
Problem 1:
When in an #if or #elif or several other kinds of tags,
ap_ssi_get_tag_and_value() is called from within a while(1) loop that
continues until that function returns with tag==NULL. But in the case of
if6.shtml, ap_ssi_get_tag_and_value() steps right past the end of the
buffer and never bothers to check and see how long the thing it's supposed
to be processing actually is. The following patch fixes it, but there
could be a better way to do it. I'm hoping someone out there who knows
this code better will come up with a better way to do it.
Index: mod_include.c
===
RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.205
diff -u -d -r1.205 mod_include.c
--- mod_include.c 24 Mar 2002 06:42:14 - 1.205
+++ mod_include.c 27 Mar 2002 06:41:55 -
@@ -866,6 +866,11 @@
int shift_val = 0;
char term = '\0';
+if (ctx->curr_tag_pos - ctx->combined_tag > ctx->tag_length) {
+*tag = NULL;
+return;
+}
+
*tag_val = NULL;
SKIP_TAG_WHITESPACE(c);
*tag = c; /* First non-whitespace character (could be NULL). */
Problem 2:
In the case of if7.shtml, for some reason, the null-terminating character
is placed one character too far forward. So instead of #endif you get
#endif\b or some such garbage:
Breakpoint 1, handle_if (ctx=0x82111b0, bb=0xb498, r=0x8226628,
f=0x8220d58, head_ptr=0x820bbd8, inserted_head=0xb044)
at mod_include.c:2552
2552{
1: *ctx = {state = PARSED, flags = 11, if_nesting_level = 0, parse_pos =
3,
bytes_parsed = 36, status = 0, output_now = 0, output_flush = 0,
head_start_bucket = 0x820bbb0, head_start_index = 0,
tag_start_bucket = 0x820bbb0, tag_start_index = 5,
tail_start_bucket = 0x820bbb0, tail_start_index = 32,
combined_tag = 0xb04c "if",
curr_tag_pos = 0xb04f "expr=\"$x = y\"\n", re_string = 0x0, re_result = 0x0}
(gdb) p ctx->curr_tag_pos - ctx->combined_tag
$3 = 3
(gdb) p ctx->curr_tag_pos+ctx->tag_length
$4 = 0xb06b "\bks"
Note the trailing \b in curr_tag_pos that shouldn't be there.
I'm at a bit of a loss on this one. I would think the problem must be in
get_combined_directive(), but I could be wrong. Again, more eyes would be
appreciated.
Thanks,
Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
RE: problem with client address/port in access_log
'never mind. It's a HP-UX specific stuff. The problem shows up because of the following reason : On HP-UX, accept has the following syntax (by default) int accept(int s, void *addr, int *addrlen); AND, socklen_t is also available. Thus, apache assumes the accept to be something like : int accept(int s, struct sockaddr *addr, socklen_t *addrlen); the problem should go away if I define _XOPEN_SOURCE_EXTENDED.. Question : can I safely assume that apache is Unix98 / X-Open sockets compatible ??. -Madhu -Original Message- From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 3:32 PM To: '[EMAIL PROTECTED]' Subject: problem with client address/port in access_log Hi, I'm trying to get apache 2.0.32 working on Itanium/HP-UX, and I'm running into the following problem : 0.0.0.0 - - [26/Mar/2002:15:27:48 -0800] "GET / HTTP/1.1" 200 1456 0.0.0.0 - - [26/Mar/2002:15:27:51 -0800] "GET /apache_pb.gif HTTP/1.1" 200 2326 I don't understand why we get 0.0.0.0.. Any ideas as to what might be happening ?.. -Madhu
[Fwd: [PATCH scoreboard] adding port entry]
Is there anything wrong with this patch? Thanks.
Original Message
Subject: [PATCH scoreboard] adding port entry
Date: Fri, 15 Mar 2002 11:58:31 +0800 (SGT)
From: Stas Bekman <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
When running port based vhosts we want to see the ports in the
mod_status's output (or other tools working with scoreboard). Otherwise
there is no added value in displaying vhosts entry at all.
The following patch adds the port entry to the worker_score struct. And
I've a patch for mod_status, but will wait first for Jeff to commit my
previous patch and the post it here.
Index: include/scoreboard.h
===
RCS file: /home/cvspublic/httpd-2.0/include/scoreboard.h,v
retrieving revision 1.44
diff -u -r1.44 scoreboard.h
--- include/scoreboard.h13 Mar 2002 20:47:42 - 1.44
+++ include/scoreboard.h15 Mar 2002 03:47:46 -
@@ -75,6 +75,7 @@
#include "apr_thread_proc.h"
#include "apr_portable.h"
#include "apr_shm.h"
+#include "apr_network_io.h"
/* Scoreboard file, if there is one */
#ifndef DEFAULT_SCOREBOARD
@@ -156,6 +157,7 @@
char client[32]; /* Keep 'em small... */
char request[64]; /* We just want an idea... */
char vhost[32]; /* What virtual host is being accessed? */
+apr_port_t port; /* On which port */
};
typedef struct {
Index: server/scoreboard.c
===
RCS file: /home/cvspublic/httpd-2.0/server/scoreboard.c,v
retrieving revision 1.62
diff -u -r1.62 scoreboard.c
--- server/scoreboard.c 13 Mar 2002 20:48:00 - 1.62
+++ server/scoreboard.c 15 Mar 2002 03:47:46 -
@@ -464,6 +464,7 @@
}
apr_cpystrn(ws->vhost, r->server->server_hostname,
sizeof(ws->vhost));
+ws->port = r->server->port;
}
}
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: make_allow
On Tue, Mar 26, 2002 at 06:40:35PM -0500, Cliff Woolley wrote: > On Tue, 26 Mar 2002, Greg Stein wrote: >... > > And empirically: mod_dav has been overriding OPTIONS for a long while now, > > and returning a list without spaces. > > Fine... but we should at least be consistent. Right now it's possible to > construct a header like this: > > Allow: GET,HEAD,POST,OPTIONS,TRACE, FOO, FAR > > because the second loop uses ", " If you want to remove the space from the second loop, then fine. When I rewrote that stuff, I just didn't care enough about the internal consistency there. Rewriting the "join" portion to use a string rather than a single character would be more work, but hey... if you want to take it on :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: [PATCH] invalid HTTP status codes in access log
On Fri, Mar 22, 2002 at 03:19:00PM -0800, Ryan Bloom wrote: > > At 05:01 PM 3/22/2002, you wrote: > > > > > Filters shouldn't return apr_status_t's, because there is nothing > > > > > that the core can do with a status code. > > > > True, they can do nothing with the apr_status_t code, any more than they > > can do anything with the HTTP_SOME_CODE or any other magic number. Untrue. apr_status_t has an application-code concept. You can define application-specific status codes that signify particular behavior to other app filters or the application that is writing to the filter stack. In general, though, you are right: most callers will just see non-zero and throw it further up the stack. > > But an apr_status_t is far more descriptive of what went wrong in the > > filter > > stack, and it doesn't bind filters as tightly to HTTP server applications. Absolutely on all accounts. I believe that I raised the issue of conflicting status/http-codes in the filter stuff well over a year ago. Some mumbles and hoohaas, and it was forgotten. > > I know there was a great deal of interest in using them in a client, and > > there will certainly be other network applications over time. Yup. The filter functions are defined in util_filter.h to return an apr_status_t. All filter functions are, in turn, declared that way. That means that returning an HTTP_FOO is totally wrong. The correct fix for logging was not to make the filters return HTTP_FOO values, but that whoever took the return value from a filter function and passed it as an http status code was broken. > > Binding the result to HTTP code seems silly, Cliff is right --- if there > > is any > > non-APR_SUCCESS result, the core should 500, something really broke. Yes. > You don't know that something really broke just because the filter had a > problem. Either the filter had a problem, or it didn't. Simple as that. It should not throw an error, if it didn't really have one. > I have written Apache filters (for 1.3) that decided > authentication based on content in the request/response files. All you > know when the filter returns is what it tells you. In this case, all it > can tell you is the HTTP response code. The filter should do the right > thing with the error code, because the core can't know what an error > code from a filter means. In this case, the filter is going to have to buffer up however much of the response is necessary until it can determine the response code. At that point, it would set the right r-> value, and then let the content through, or replace it with error content. In either case, it probably is not returning an error up the filter stack. If it *did* do that, then the filter is signifying that an *error* occurred, and the application will probably stop all processing. You could also say that it returns APR_OS_START_USEERR+1 to signify the authentication problem. The app then maps that to HTTP_UNAUTHORIZED. But to tie the filter stack to HTTP_ error codes is wrong. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: make_allow
On Tue, 26 Mar 2002, Cliff Woolley wrote: > ..., FOO, FAR I can't even spell BAR right today. What a world, what a world. ;) -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
On Tue, 26 Mar 2002, Greg Stein wrote: > D'oh!!! > I generated the input from the M_FOO symbols. Of course, there isn't an > M_HEAD symbol, so... > :-) > Thanks for fixing this! No problem! --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: make_allow
On Tue, 26 Mar 2002, Greg Stein wrote: > It's valid behavior (whitespace is allowed in any comma-separated list > unless explicitly specified otherwise). Yeah, I finally found that in the grammar. Thanks. > And empirically: mod_dav has been overriding OPTIONS for a long while now, > and returning a list without spaces. Fine... but we should at least be consistent. Right now it's possible to construct a header like this: Allow: GET,HEAD,POST,OPTIONS,TRACE, FOO, FAR because the second loop uses ", " --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: SCOREBOARD_FILE
On Tue, Mar 26, 2002 at 12:13:35PM -0500, Jim Jagielski wrote: > ... maybe it's time to depreciate this :) In what way: the #define or the file itself? -aaron
Re: HTTP 404 Served As text/plain UPDATE
On Tue, 26 Mar 2002, Bill Stoddard wrote: > No comments on whether this patch is correct in concept or not. However, it is >definitely > broken if you do not use ap_set_content_type() to set the content type. By the way, why don't we enforce this type of thing by making these portions of the structure opaque? There are a bunch of cases, notably in the request rec, where there are rules like this that are not enforced by the compiler. sterling
Re: cvs commit: httpd-2.0/modules/http http_protocol.c
On Mon, Mar 25, 2002 at 01:10:06AM -, [EMAIL PROTECTED] wrote: > jwoolley02/03/24 17:10:06 > > Modified:modules/http http_protocol.c > Log: > What, we don't support HEAD requests now? ;) D'oh!!! I generated the input from the M_FOO symbols. Of course, there isn't an M_HEAD symbol, so... :-) Thanks for fixing this! CHeers, -g -- Greg Stein, http://www.lyra.org/
Re: make_allow
On Sun, Mar 24, 2002 at 09:48:24PM -0500, Cliff Woolley wrote: > > There are two problems I see with make_allow() right now. First, it's > using method_registry; if ap_method_register() has never been called > [probably meaning you aren't running DAV], then make_allow() will segfault > as Brian pointed out. ap_method_registry_init() needs to be called > unconditionally from somewhere. I haven't figured out where that is yet. Server initialization. I believe the pool passed to it is normally pconf (via post_config). Which basically means that running it after each call to ap_run_post_config() should be sufficient. That means server/main.c, which then implies right before ap_mpm_run(). (there are two calls to ap_run_post_config, but there is no need to do it after the first run, since you're about to wipe the pool anyways) > Second, the Allow: header is now separated by "," instead of ", " -- > RFC2616 doesn't seem to specify whether that's valid or not, but we should > probably keep the old behavior. Unfortunately apr_array_pstrcat (called > from line 1123 of http_protocol.c) only accepts a single character, not a > string, as the delimiter. Ideas? It's valid behavior (whitespace is allowed in any comma-separated list unless explicitly specified otherwise). And empirically: mod_dav has been overriding OPTIONS for a long while now, and returning a list without spaces. Cheers, -g -- Greg Stein, http://www.lyra.org/
problem with client address/port in access_log
Hi, I'm trying to get apache 2.0.32 working on Itanium/HP-UX, and I'm running into the following problem : 0.0.0.0 - - [26/Mar/2002:15:27:48 -0800] "GET / HTTP/1.1" 200 1456 0.0.0.0 - - [26/Mar/2002:15:27:51 -0800] "GET /apache_pb.gif HTTP/1.1" 200 2326 I don't understand why we get 0.0.0.0.. Any ideas as to what might be happening ?.. -Madhu
Re: HTTP 404 Served As text/plain UPDATE
On Tue, 26 Mar 2002, Bill Stoddard wrote: > No comments on whether this patch is correct in concept or not. However, it is >definitely > broken if you do not use ap_set_content_type() to set the content type. yeah - i did not put [PATCH] in the subject because this is not a suggested patch to fix the problem - but to help shed light on the problem. The real problem, i think, is that the content type is not being propagated up in this case. The module should not be responsible for this decision. sterling
Re: cvs commit: apache-1.3/src/main http_protocol.c
On Thu, Mar 21, 2002 at 02:49:47PM -, [EMAIL PROTECTED] wrote:
>...
> +++ http_protocol.c 21 Mar 2002 14:49:46 - 1.312
>...
> +/* keep a previously set server header (possible from proxy), otherwise
> + * generate a new server header */
> +if (server = ap_table_get(r->headers_out, "Server")) {
To avoid warnings on some compilers, this assignment should have extra stuff
around it to prevent a warning about possible typo'ing of "==". For example:
if ((server = ap_table_get(r->headers_out, "Server")) != NULL) {
Just a standard rule to apply for any construct like this you do...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Hold off on 2.0.34 for a few minutes?
On Tue, Mar 26, 2002 at 11:45:54AM -0800, Justin Erenkrantz wrote: > On Tue, Mar 26, 2002 at 11:39:07AM -0800, Ryan Bloom wrote: > > Do we have a script that does the directory creation now? I have always > > just created all dirs by hand. > > As I understand our policy to be, configure should magically create > all directories for you. (And, we mostly do this.) > > However, I know people have complained that we aren't always > consistent about that (most notably w.r.t. expat-lite in > apr-util). -- justin configure will only create the directories for files passed to AC_OUTPUT(). Since we have a replacement for that (bogus, IMO), that means we must manually create directories for the FAST_OUTPUT items. [ btw, what do you mean "expat-lite" in apr-util? there is no such thing. We have a full copy of Expat in there, in case the target system doesn't have expat already installed. ] Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: HTTP 404 Served As text/plain UPDATE
No comments on whether this patch is correct in concept or not. However, it is
definitely
broken if you do not use ap_set_content_type() to set the content type.
Bill
> On Tue, 26 Mar 2002, Jerry Baker wrote:
>
> > Jerry Baker wrote:
> > >
> > > I just noticed something about this problem. If you request
> > > /nonexistentfile.html then the error response is sent back with
> > > text/html, but if you request /nonexistentfile then it still comes back
> > > as text/plain.
> > >
> > > --
> > > Jerry Baker
> >
> > Not only that. If you request /nonexistentfile.exe, it gets sent back as
> > application/octet-stream. The ErrorDocument is being returned with
> > whatever content-type matches the file extension of the requested
> > document. I doubt many people want to download the ErrorDocument in the
> > case that they request a non-existent application/octet-stream URI.
>
>
> yeah - the sub request content type is getting set by negotiation, but it
> is not being propagated up. i am not sure how this is supposed to take
> place, but the following patch actually makes the content type set
> properly in my test cases. although i don't think its the right fix -
> isn't that content type supposed to be propagated? i know this stuff is
> kinda whacky - maybe this sheds some light on the situation. anyways
> here's the patch
>
> Index: modules/mappers/mod_negotiation.c
> ===
> RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_negotiation.c,v
> retrieving revision 1.100
> diff -u -r1.100 mod_negotiation.c
> --- modules/mappers/mod_negotiation.c 20 Mar 2002 17:41:55 - 1.100
> +++ modules/mappers/mod_negotiation.c 26 Mar 2002 20:54:33 -
> @@ -942,10 +942,13 @@
> }
> else if (!strncmp(buffer, "content-type:", 13)) {
> struct accept_rec accept_info;
> +request_rec *tmp_req;
>
> get_entry(neg->pool, &accept_info, body);
> set_mime_fields(&mime_info, &accept_info);
> has_content = 1;
> +for( tmp_req = r; tmp_req != NULL; tmp_req = tmp_req->prev )
> +tmp_req->content_type = mime_info.mime_type;
> }
> else if (!strncmp(buffer, "content-length:", 15)) {
> mime_info.bytes = atol(body);
>
Re: HTTP 404 Served As text/plain UPDATE
On Tue, 26 Mar 2002, Jerry Baker wrote:
> Jerry Baker wrote:
> >
> > I just noticed something about this problem. If you request
> > /nonexistentfile.html then the error response is sent back with
> > text/html, but if you request /nonexistentfile then it still comes back
> > as text/plain.
> >
> > --
> > Jerry Baker
>
> Not only that. If you request /nonexistentfile.exe, it gets sent back as
> application/octet-stream. The ErrorDocument is being returned with
> whatever content-type matches the file extension of the requested
> document. I doubt many people want to download the ErrorDocument in the
> case that they request a non-existent application/octet-stream URI.
yeah - the sub request content type is getting set by negotiation, but it
is not being propagated up. i am not sure how this is supposed to take
place, but the following patch actually makes the content type set
properly in my test cases. although i don't think its the right fix -
isn't that content type supposed to be propagated? i know this stuff is
kinda whacky - maybe this sheds some light on the situation. anyways
here's the patch
Index: modules/mappers/mod_negotiation.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/mappers/mod_negotiation.c,v
retrieving revision 1.100
diff -u -r1.100 mod_negotiation.c
--- modules/mappers/mod_negotiation.c 20 Mar 2002 17:41:55 - 1.100
+++ modules/mappers/mod_negotiation.c 26 Mar 2002 20:54:33 -
@@ -942,10 +942,13 @@
}
else if (!strncmp(buffer, "content-type:", 13)) {
struct accept_rec accept_info;
+request_rec *tmp_req;
get_entry(neg->pool, &accept_info, body);
set_mime_fields(&mime_info, &accept_info);
has_content = 1;
+for( tmp_req = r; tmp_req != NULL; tmp_req = tmp_req->prev )
+tmp_req->content_type = mime_info.mime_type;
}
else if (!strncmp(buffer, "content-length:", 15)) {
mime_info.bytes = atol(body);
Re: cvs commit: httpd-2.0/include ap_release.h
At 02:41 PM 3/26/2002, you wrote: > Log: > Up to .35 [no need to call out .35-dev in changes, that's just silly.] Cliff and Brian, when your code is committed, please highlight the file/versions you need pushed into the _34 tag, and I'll get those in. Bill
Re: Open Apache 2.0 Bug Summary
On Tue, Mar 26, 2002 at 03:09:21PM -0500, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > Yep. i think it's fixed.. Here's a output from one of the configure command > that I'd run some time back. I'll try it out again and let you know the > results. > > checking size of long long... 8 > checking for INT64_C... no > checking for INT64_C in stdint.h... (cached) no > checking size of ssize_t... 4 Hmm. Based on that PR, it sounds like INT64_C should have been detected without doing anything (i.e. the first INT64_C should have passed). Can you please take a look at the PR and see if the report makes any sense? I don't think that the change will hurt us, but it'd be nice to be able to reproduce this PR. -- justin
RE: Open Apache 2.0 Bug Summary
Yep. i think it's fixed.. Here's a output from one of the configure command that I'd run some time back. I'll try it out again and let you know the results. checking size of long long... 8 checking for INT64_C... no checking for INT64_C in stdint.h... (cached) no checking size of ssize_t... 4 -Madhu -Original Message- From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 11:57 AM To: [EMAIL PROTECTED] Subject: Re: Open Apache 2.0 Bug Summary On Tue, Mar 26, 2002 at 01:57:45AM -0600, William A. Rowe, Jr. wrote: > 8932 config Configure claims that the header file "stdint.h" exists because > STD64_C is def Should be fixed by revision 1.421 of apr's configure.in. Can someone with HP-UX's ANSI C compiler verify this? -- justin
Re: Hold off on 2.0.34 for a few minutes?
On Tue, Mar 26, 2002 at 01:59:27PM -0600, William A. Rowe, Jr. wrote: > At 01:38 PM 3/26/2002, you wrote: > >On Tue, Mar 26, 2002 at 11:32:12AM -0800, Ryan Bloom wrote: > > > VPATH builds worked just last night, how can they be broken now? > > > >Doesn't create the build/ directory under top_builddir. Errors out > >when trying to create build/config_vars.mk. > > > >Just need to create the dir. It's a quick fix, but I'm trying to > >test it before committing. -- justin > > Please advise when you have committed -and- tested thoroughly. It works here on my systems in the combinations I tried. The patch seems fairly obvious. I took advantage of the fact that at this stage of configure we know if mkdir -p works. Didn't have to do that, but oh well. -- justin
Re: Open Apache 2.0 Bug Summary
On Tue, Mar 26, 2002 at 01:57:45AM -0600, William A. Rowe, Jr. wrote: > 9361 build expat, manualdir and Makefile fixes Confirmed that all of these patches have already been incorporated in some fashion. PR closed. -- justin
Re: server-status
Daniel Abad wrote: > > Hi all! > > I´m having a little problem with server-status that it´s returning me > forbidden every time i try it. Below you can see my configuration in > httpd.conf, and the error returned in the logs. > > > SetHandler server-status > Order deny,allow > Deny from all > Allow from localhost > > > [Sun Mar 17 18:24:59 2002] [error] [client 127.0.0.1] client denied by > server configuration: /home/vhosts/l > > As you can see i´m using mod_vhosts compiled into apache, and also mod_info > and mod_status. The strange thing is when i open the permition to Allow all > and coment the deny line, it works fine, but for security reasons it can´t > happens. > > Anyone can help me? > > Thaks in advanced. > > Dan. Try changing "localhost" to "127.0.0.1". I imagine that Apache never sees that your machine is called "localhost" since it is probably not set up to resolve IP addresses accessing it. -- Jerry Baker
server-status
Hi all! I´m having a little problem with server-status that it´s returning me forbidden every time i try it. Below you can see my configuration in httpd.conf, and the error returned in the logs. SetHandler server-status Order deny,allow Deny from all Allow from localhost [Sun Mar 17 18:24:59 2002] [error] [client 127.0.0.1] client denied by server configuration: /home/vhosts/l As you can see i´m using mod_vhosts compiled into apache, and also mod_info and mod_status. The strange thing is when i open the permition to Allow all and coment the deny line, it works fine, but for security reasons it can´t happens. Anyone can help me? Thaks in advanced. Dan.
Re: HTTP 404 Served As text/plain UPDATE
Jerry, thanks for the detailed analysis... sure sounds like you've hit the nail on the head. When we 'tag' .34 - we won't be rolling it. I will personally be looking at this quirk in the next day or two, and so may others. If a patch is prepared that 'fits' [increases stability - doesn't restructure a ton of code] then we will 'roll it in' to .34. Agreed that this isn't nice behavior, but also recognize that this is one bug in many, and many are now fixed and many others may yet be unspotted. We want to get something into folks hands, even if it is only 'alpha' quality. Release early, release often assures that many more bugs are fixed much more quickly. Bill At 01:00 PM 3/26/2002, you wrote: >Jerry Baker wrote: > > > > I just noticed something about this problem. If you request > > /nonexistentfile.html then the error response is sent back with > > text/html, but if you request /nonexistentfile then it still comes back > > as text/plain. > > > > -- > > Jerry Baker > >Not only that. If you request /nonexistentfile.exe, it gets sent back as >application/octet-stream. The ErrorDocument is being returned with >whatever content-type matches the file extension of the requested >document. I doubt many people want to download the ErrorDocument in the >case that they request a non-existent application/octet-stream URI. > >-- >Jerry Baker
Re: Hold off on 2.0.34 for a few minutes?
At 01:38 PM 3/26/2002, you wrote: >On Tue, Mar 26, 2002 at 11:32:12AM -0800, Ryan Bloom wrote: > > VPATH builds worked just last night, how can they be broken now? > >Doesn't create the build/ directory under top_builddir. Errors out >when trying to create build/config_vars.mk. > >Just need to create the dir. It's a quick fix, but I'm trying to >test it before committing. -- justin Please advise when you have committed -and- tested thoroughly. Bill
Re: Open Apache 2.0 Bug Summary
On Tue, Mar 26, 2002 at 01:57:45AM -0600, William A. Rowe, Jr. wrote: > 8932 config Configure claims that the header file "stdint.h" exists because > STD64_C is def Should be fixed by revision 1.421 of apr's configure.in. Can someone with HP-UX's ANSI C compiler verify this? -- justin
Re: Hold off on 2.0.34 for a few minutes?
On Tue, Mar 26, 2002 at 11:39:07AM -0800, Ryan Bloom wrote: > Do we have a script that does the directory creation now? I have always > just created all dirs by hand. As I understand our policy to be, configure should magically create all directories for you. (And, we mostly do this.) However, I know people have complained that we aren't always consistent about that (most notably w.r.t. expat-lite in apr-util). -- justin
RE: Hold off on 2.0.34 for a few minutes?
Do we have a script that does the directory creation now? I have always just created all dirs by hand. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -Original Message- > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 11:38 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Hold off on 2.0.34 for a few minutes? > > On Tue, Mar 26, 2002 at 11:32:12AM -0800, Ryan Bloom wrote: > > VPATH builds worked just last night, how can they be broken now? > > Doesn't create the build/ directory under top_builddir. Errors out > when trying to create build/config_vars.mk. > > Just need to create the dir. It's a quick fix, but I'm trying to > test it before committing. -- justin
Re: Hold off on 2.0.34 for a few minutes?
On Tue, Mar 26, 2002 at 11:32:12AM -0800, Ryan Bloom wrote: > VPATH builds worked just last night, how can they be broken now? Doesn't create the build/ directory under top_builddir. Errors out when trying to create build/config_vars.mk. Just need to create the dir. It's a quick fix, but I'm trying to test it before committing. -- justin
RE: Hold off on 2.0.34 for a few minutes?
VPATH builds worked just last night, how can they be broken now? Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -Original Message- > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 11:31 AM > To: [EMAIL PROTECTED] > Subject: Hold off on 2.0.34 for a few minutes? > > VPATH builds are broken. I'm trying to fix it right now, so if > we can hold off until I get that fix in, I'd appreciate it. > > Should be in by noon, but just in case I get waylaid... -- justin
Hold off on 2.0.34 for a few minutes?
VPATH builds are broken. I'm trying to fix it right now, so if we can hold off until I get that fix in, I'd appreciate it. Should be in by noon, but just in case I get waylaid... -- justin
Re: HTTP 404 Served As text/plain UPDATE
Jerry Baker wrote: > > I just noticed something about this problem. If you request > /nonexistentfile.html then the error response is sent back with > text/html, but if you request /nonexistentfile then it still comes back > as text/plain. > > -- > Jerry Baker Not only that. If you request /nonexistentfile.exe, it gets sent back as application/octet-stream. The ErrorDocument is being returned with whatever content-type matches the file extension of the requested document. I doubt many people want to download the ErrorDocument in the case that they request a non-existent application/octet-stream URI. -- Jerry Baker
RE: Open Apache 2.0 Bug Summary
I am close to fixing perchild. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -Original Message- > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 10:51 AM > To: [EMAIL PROTECTED] > Subject: Re: Open Apache 2.0 Bug Summary > > On Tue, Mar 26, 2002 at 01:57:45AM -0600, William A. Rowe, Jr. wrote: > > 8845 os-sunos Apache 2.0.28 beta does not compile under Solaris 8 (both > > Intel and Sparc) using perchild MPM > > We should indicate that perchild is experimental. However, I won't > close this bug or append a note though. I'll leave that to someone > who might know more about perchild. -- justin
Re: Open Apache 2.0 Bug Summary
On Tue, Mar 26, 2002 at 01:57:45AM -0600, William A. Rowe, Jr. wrote: > 8845 os-sunos Apache 2.0.28 beta does not compile under Solaris 8 (both > Intel and Sparc) using perchild MPM We should indicate that perchild is experimental. However, I won't close this bug or append a note though. I'll leave that to someone who might know more about perchild. -- justin
Re: Open Apache 2.0 Bug Summary
On Tue, Mar 26, 2002 at 01:57:45AM -0600, William A. Rowe, Jr. wrote: > 7730 config magic file is a bit outdated Just committed the relevant bits to both 1.3 and 2.0 trees for this and closed the PR. Working my way through the rest of them... -- justin
Re: 2.0.34 tag planned for 1200 PST 03-26-02
Sander Striker wrote: > > +1 for the API changes to be committed (with the simple malloc implementation). > We can fill in the actual implementation in the upcomming week. > +1. -- justin
SCOREBOARD_FILE
... maybe it's time to depreciate this :) -- === 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: Open Apache 2.0 Bug Summary
Cliff Woolley wrote: >On Tue, 26 Mar 2002, Greg Ames wrote: > >>>9676 mod_cgi 2.0.18 reading from CGI programs is very inefficient >>> >>BrianP committed a fix for this very recently. >> > >I thought only mod_cgi was fixed but mod_cgid was still outstanding? > Right, mod_cgid still does single-byte reads (but I should be able to fix it this weekend). --Brian
Re: Open Apache 2.0 Bug Summary
On Tue, 26 Mar 2002, Greg Ames wrote: > > 9676 mod_cgi 2.0.18 reading from CGI programs is very inefficient > > BrianP committed a fix for this very recently. I thought only mod_cgi was fixed but mod_cgid was still outstanding? --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: Open Apache 2.0 Bug Summary
"William A. Rowe, Jr." wrote: > 9676 mod_cgi 2.0.18 reading from CGI programs is very inefficient BrianP committed a fix for this very recently. Greg
Re: 2.0.34 tag planned for 1200 PST 03-26-02
Sander Striker wrote: > > +1 for the API changes to be committed (with the simple malloc implementation). > We can fill in the actual implementation in the upcomming week. > +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: 2.0.34 tag planned for 1200 PST 03-26-02
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]] > Sent: 26 March 2002 09:08 > On Tue, 26 Mar 2002, William A. Rowe, Jr. wrote: > > > If you and Cliff know that's a stable patch, safe for inclusion this > > time around, and helpful to implementors [because you promise > > not to break the API just as soon as you've first implemented it ;-] > > then I'd love to see that committed in the morning. > > Will do. It will be after noon EST because I have class all morning, but > before 1200 PST is no problem. > > --Cliff +1 for the API changes to be committed (with the simple malloc implementation). We can fill in the actual implementation in the upcomming week. Sander
Re: 2.0.34 tag planned for 1200 PST 03-26-02
Greg Ames <[EMAIL PROTECTED]> writes: > Jeff Trawick wrote: > > > At the moment, I don't see anybody lined up to put it on daedalus and > > run apache.org on it for a few days. > > I'm lined up. I'd prefer using tagged code which includes the new bucket API. And I don't blame you one bit!!! It is certainly fair to make that an absolutely requirement for involvement, since otherwise there is the risk that you (or me or anybody else) would need to repeat the effort before long. --- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: 2.0.34 tag planned for 1200 PST 03-26-02
Jeff Trawick wrote: > At the moment, I don't see anybody lined up to put it on daedalus and > run apache.org on it for a few days. I'm lined up. I'd prefer using tagged code which includes the new bucket API. Greg
Re: Open Apache 2.0 Bug Summary
On Tue, Mar 26, 2002 at 06:55:35AM -0800, Aaron Bannert wrote: > On Tue, Mar 26, 2002 at 09:47:24AM +, Thom May wrote: > > 9827 and 9886 are definitely fixed. > > Yup, I [mostly] fixed those, I'll close them now. thanks, (it must be too early to be writing to dev@httpd). Of course I don't mean that I was the only one who helped fix these. Thom did at least as much work on it as I did. :) -aaron
Re: Open Apache 2.0 Bug Summary
On Tue, Mar 26, 2002 at 09:47:24AM +, Thom May wrote: > 9827 and 9886 are definitely fixed. Yup, I [mostly] fixed those, I'll close them now. thanks, aaron
Re: 2.0.34 tag planned for 1200 PST 03-26-02
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes: > I don't want to see us wait until April to circulate new, good code to our > patient and dedicated testers. We are really overdue for a beta. yep... it is definitely taking too long... a number of bug reports for stuff already fixed, a number of closed bug reports where users need the opportunity to get the new code and verify for themselves I'm glad you're pushing this. >OTOH, > I don't need people moaning that I've just 'grabbed' a tag. There is no reason for people to moan about that (but then you already knew that :) ). But a practical issue to consider, which is somewhat related to the moaning, is that it takes a lot of effort to put out a decent beta, so if you want to tag in hopes of capturing code that can be released as a beta then you'll need to line up some help too. (As for me personally, I can make a fair amount of Wednesday/Thursday available to help out.) At the moment, I don't see anybody lined up to put it on daedalus and run apache.org on it for a few days. If my memory serves correctly, that has always uncovered some issues. Just as importantly, it has given us a lot more confidence in the stability of the code. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Open Apache 2.0 Bug Summary
9827 and 9886 are definitely fixed. -Thom
Re: 2.0.34 tag planned for 1200 PST 03-26-02
"William A. Rowe, Jr." wrote: > > With no objections ... I'll grab a tag at the appointed time and we can > spend a day differing over what patches should be rolled in/rolled out > of that tag for a real candidate. > > Bill I know I have no meaningful say in the matter, but shouldn't a beta be able to serve an ErrorDocument with the correct content-type? The bug still exists. -- Jerry Baker
HTTP 404 Served As text/plain UPDATE
I just noticed something about this problem. If you request /nonexistentfile.html then the error response is sent back with text/html, but if you request /nonexistentfile then it still comes back as text/plain. -- Jerry Baker
