Re: [PATCH httpd 1.2] chunk size overflow
At 09:49 PM 6/20/2002, Jim Jagielski wrote: >Cliff Woolley wrote: > > > > On Thu, 20 Jun 2002, Roy T. Fielding wrote: > > > > > This patch should be sufficient to fix the security hole for most > > > versions of Apache httpd 1.2. Should we put it up on dist/httpd? > > > > What about the proxy? > > > >Not really a problem with 1.2, or other non HTTP/1.1 proxies I think :) Not a problem, IIRC, until we introduced 1.3.24 with the HTTP/1.1 proxy. Bill
Re: Content-Length specifics
At 09:11 PM 6/20/2002, Jim Jagielski wrote: >Is whitespace allowed after the value set in Content-Length? eg: > >Content-Length: 12344 \r\n That falls under the generic LWS rule. Bill
Re: Content-Length specifics
On Thu, 20 Jun 2002, Justin Erenkrantz wrote: > But, the key thing to remember is that headers are stripped of > trailing spaces before they are placed in the table. Ahh, that is the key. Thanks.
Re: Content-Length specifics
On Fri, Jun 21, 2002 at 12:56:47AM -0400, Cliff Woolley wrote: > On Thu, 20 Jun 2002, Justin Erenkrantz wrote: > > > I believe so. Our current implementation supports it. -- justin > > Does 1.3's now that we've changed it? I don't see why strtol wouldn't parse that. But, the key thing to remember is that headers are stripped of trailing spaces before they are placed in the table. So, in practice, we'll never see trailing spaces. -- justin
Re: Content-Length specifics
On Thu, 20 Jun 2002, Justin Erenkrantz wrote: > I believe so. Our current implementation supports it. -- justin Does 1.3's now that we've changed it? --Cliff
Re: Content-Length specifics
On Thu, Jun 20, 2002 at 10:11:18PM -0400, Jim Jagielski wrote: > Is whitespace allowed after the value set in Content-Length? eg: > >Content-Length: 12344 \r\n > ^^ I believe so. Our current implementation supports it. -- justin
Re: [PATCH httpd 1.2] chunk size overflow
Cliff Woolley wrote: > > On Thu, 20 Jun 2002, Roy T. Fielding wrote: > > > This patch should be sufficient to fix the security hole for most > > versions of Apache httpd 1.2. Should we put it up on dist/httpd? > > What about the proxy? > Not really a problem with 1.2, or other non HTTP/1.1 proxies I think :) -- === 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: [PATCH httpd 1.2] chunk size overflow
On Thu, 20 Jun 2002, Roy T. Fielding wrote: > This patch should be sufficient to fix the security hole for most > versions of Apache httpd 1.2. Should we put it up on dist/httpd? What about the proxy? --Cliff
Content-Length specifics
Is whitespace allowed after the value set in Content-Length? eg: Content-Length: 12344 \r\n ^^ -- === 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
[PATCH httpd 1.2] chunk size overflow
This patch should be sufficient to fix the security hole for most
versions of Apache httpd 1.2. Should we put it up on dist/httpd?
Roy
--- apache-1.2/src/http_protocol.c Thu Jan 4 01:21:10 2001
+++ apache-1.2/src/patched_http_protocol.c Thu Jun 20 18:13:04 2002
@@ -1535,6 +1535,10 @@
}
len_to_read = get_chunk_size(buffer);
+if (len_to_read < 0) {
+r->connection->keepalive = -1;
+return -1;
+}
if (len_to_read == 0) { /* Last chunk indicated, get footers */
if (r->read_body == REQUEST_CHUNKED_DECHUNK) {
Re: 2.0.38-39 lockup problem ?
This looks exactly like the problem that Allan and I ran into when you
tried to send a request to http://foo.bar.org:443 (i.e. insecure request
over the secure port). It tried to generate an error and went into an
infinte loop. That special case was fixed by removing the SSL request
handler from the loop. This may be a bigger problem than that specific
case (or this one).
I seem to recall that the error gets created as a new request in the
ap_internal_redirect case. This seemed to cause the code to process it
from scratch. This prompted the same error to occur, etc.
Perhaps something needs to be setup or tagged differently so that the
error doesn't go back through all the same code that generated the
error condition in the first place. Just a clueless guess on my part.
Paul J. Reder
Greg Ames wrote:
> Colm MacCárthaigh wrote:
>
>
>>also; anyone looking to replicate, I can produce it from a vanilla
>>install by adding:
>>
>>RewriteCond %{HTTP_HOST}!monkey$[NC]
>>RewriteRule ^(.+)$ banana
>>
>>at the bottom of the standard httpd.conf , a request with a host
>>header anything other than monkey will hang the server. I've
>>just rebuilt 2.0.36 and tested against the same vailla config
>>and it doesnt happen.
>>
>
> OK, with this config I can easily duplicate the problem on .39 but not .36.
> ap_die lost its recursive error defense mechanism.
>
> We get there because mod_rewrite sees that there is a rule that maps any uri
> (including the error document uri) to "banana", then calls
> ap_os_is_path_absolute("banana"). It isn't absolute, so mod_rewrite sets a 400
> error and bails. In .36, the brower gets the canned error strings that
> indicates recursive 400 errors. In .39, we get:
>
> #0 ap_die (type=400, r=0x860ddb8) at http_request.c:130
> #1 0x08066d59 in ap_internal_redirect (
> new_uri=0x80e36c0 "/error/HTTP_BAD_REQUEST.html.var", r=0x85e2d10)
> at http_request.c:482
> #2 0x08066675 in ap_die (type=400, r=0x85e2d10) at http_request.c:187
> #3 0x08066d59 in ap_internal_redirect (
> new_uri=0x80e36c0 "/error/HTTP_BAD_REQUEST.html.var", r=0x85b9af8)
> at http_request.c:482
> #4 0x08066675 in ap_die (type=400, r=0x85b9af8) at http_request.c:187
> #5 0x08066d59 in ap_internal_redirect (
> new_uri=0x80e36c0 "/error/HTTP_BAD_REQUEST.html.var", r=0x858e590)
> at http_request.c:482
>
> etc etc
>
> I just committed a fix to http_protocol.c::ap_die which backs out part of rev
> 1.145. This restores the recursive error protection which is pretty important
> IMO. We can rework the fix to 1.145 if we need to.
>
> Greg
>
>
>
--
Paul J. Reder
---
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: cvs commit: httpd-2.0/modules/http http_request.c
On Thu, Jun 20, 2002 at 05:30:52PM -0400, Greg Ames wrote: > No sir. That's just one way to cause recursive errors. The code in ap_die that > detects and prevents infinite recursive errors was written for a reason. If we > cripple it, Apache becomes less robust. No, this isn't stopping all recursive errors - it's stopping a certain class of errors that are at the heart of the protocol dealing with user input. Recursive errors still work, but only for ones that are internal to the server. Any error that deals with the invalidity of the client request shouldn't be recursive (that means we're parsing it twice). The 400 from mod_rewrite is wrong in any case - the resource is not found or it is a misconfiguration in the server rules. A 400 should only be for syntactical protocol errors. There is nothing invalid in the request that was sent to mod_rewrite - other than the fact that it could not find the resource. I believe that is a 404 (which doesn't drop the connection). > We ought to be able to have our cake and eat it too. It is easy to turn off > keepalives based on the original "type" passed to ap_die. I think you're saying > there's now a dependency that r->status matches the original "type" on exit, > right? Only where ap_status_drops_connection is true. The problem before was that if you got a 404 and then got a 413 on the discard, it would revert the status to a 404 and then try to read the body as part of the handlers in serving the error page. We simply can not do that - so the status can't be 404 when we get a 413 - it must be a 413. When we are supposed to drop the connection, r->status *must* indicate that. -- justin
Re: cvs commit: httpd-2.0/docs/error/include bottom.html
Justin Erenkrantz wrote: > On Thu, Jun 20, 2002 at 03:04:07PM -0400, Joshua Slive wrote: > > Someone snuck in and moved the furniture on you while you were > sleeping (i.e. follow the source). > > SERVER_SOFTWARE is the variable used by error/include/bottom.html. > That is added in ap_add_common_vars() in server/util_script.c:268. > That calls ap_get_server_version() which is the same call used to > populate the Server HTTP header (see basic_http_header in > http_protocol.c). That call just returns the server_version > variable in server/core.c. And, the ServerTokens directive controls > that value. -- justin Ok. I missed that. It certainly isn't documented at all, which is a problem because it could break CGI scripts. Joshua.
Re: cvs commit: httpd-2.0/modules/http http_request.c
Greg Ames wrote:
> We ought to be able to have our cake and eat it too.
What about this?
Index: modules/http/http_request.c
===
RCS file: /home/cvs/httpd-2.0/modules/http/http_request.c,v
retrieving revision 1.148
diff -u -d -b -r1.148 http_request.c
--- modules/http/http_request.c 20 Jun 2002 19:34:28 - 1.148
+++ modules/http/http_request.c 20 Jun 2002 21:56:03 -
@@ -120,10 +120,12 @@
if (r->status != HTTP_OK) {
recursive_error = type;
+if (!ap_status_drops_connection(type)) {
while (r->prev && (r->prev->status != HTTP_OK))
r = r->prev;/* Get back to original error */
type = r->status;
+}
custom_response = NULL; /* Do NOT retry the custom thing! */
}
Actually, I think we can do better, but my dog needs to go outside soon. It
bothers me that this is changing/not changing the r that the rest of the
function uses depending on the status code. I think the main reason that it
looks for the original error is so that ap_send_error_resonse can report both
errors when there are recursive errors. We could use a different variable than
r here (so the original r never gets changed) and pass that to
ap_send_error_response, and also avoid whacking "type".
Greg
Re: [TEST PLEASE!!] apache 1.3 and 2.0 nearing release
At 04:41 PM 6/20/2002, you wrote: >Hi Bill, > > > Well it's been that way since I created the .dsp file. We can look for > > both inc32 and include, > > both libpaths out32dll and (???). And check bin for .exe's. That doesn't > > bother me at all. >ok, was my fault: >I moved to another build machine, and on my old one I had the paths to >openssl entered in the IDE, so the files were always found... Doesn't matter. I suspect you are right, that other folks are using very common alternate paths of openssl/include[/openssl] and openssl/??? for binaries (such as openssl.exe) and openssl/??? for the debug and release libraries. What would those paths be for your installation, and how did you come to those paths (e.g. which doc or install utility?) Bill
Re: cvs commit: httpd-2.0/modules/http http_request.c
On Thu, Jun 20, 2002 at 05:30:52PM -0400, Greg Ames wrote: > We ought to be able to have our cake and eat it too. It is easy to turn off > keepalives based on the original "type" passed to ap_die. I think you're saying > there's now a dependency that r->status matches the original "type" on exit, > right? Maybe I'm reading you wrong, but I've always noticed quiet a few situations in which the status gets changed depending on how the error is handled. Off the top of my head one is when the $PREFIX/error directory is inaccessible , you can end up with HTTP 403's instead of 404's, 401's .. et al. The latter being really annoying because the WWW-Authenticate: header is present, and the request would work just fine, if it only had a 401 status. -- [EMAIL PROTECTED]PubKey: [EMAIL PROTECTED] Web: http://devnull.redbrick.dcu.ie/
Re: [TEST PLEASE!!] apache 1.3 and 2.0 nearing release
Hi Bill, > Well it's been that way since I created the .dsp file. We can look for > both inc32 and include, > both libpaths out32dll and (???). And check bin for .exe's. That doesn't > bother me at all. ok, was my fault: I moved to another build machine, and on my old one I had the paths to openssl entered in the IDE, so the files were always found... Guenter.
Re: cvs commit: httpd-2.0/modules/http http_request.c
Justin Erenkrantz wrote: > > On Thu, Jun 20, 2002 at 04:08:38PM -0400, Greg Ames wrote: > > We cannot tolerate infinite recursion if an ErrorDocument gets an error. The if > > statement I changed is how we detect this sort of recursive error. Please take > > a look at the backtrace I posted to [EMAIL PROTECTED], under the subject > > "2.0.38-39 lockup problem ?". > > > > If we need to prevent reading the body for certain types of errors, we can't do > > it at the expense of loosing our recursive error protection. > > The problem is that mod_rewrite is taking what we *know* to be a > valid URL (based on the ErrorDocuments directive) and translating > it to an invalid one that generates a 400. Fix that. No sir. That's just one way to cause recursive errors. The code in ap_die that detects and prevents infinite recursive errors was written for a reason. If we cripple it, Apache becomes less robust. We ought to be able to have our cake and eat it too. It is easy to turn off keepalives based on the original "type" passed to ap_die. I think you're saying there's now a dependency that r->status matches the original "type" on exit, right? Greg
Re: cvs commit: httpd-2.0/modules/http http_request.c
On Thu, Jun 20, 2002 at 04:08:38PM -0400, Greg Ames wrote: > We cannot tolerate infinite recursion if an ErrorDocument gets an error. The if > statement I changed is how we detect this sort of recursive error. Please take > a look at the backtrace I posted to [EMAIL PROTECTED], under the subject > "2.0.38-39 lockup problem ?". > > If we need to prevent reading the body for certain types of errors, we can't do > it at the expense of loosing our recursive error protection. The problem is that mod_rewrite is taking what we *know* to be a valid URL (based on the ErrorDocuments directive) and translating it to an invalid one that generates a 400. Fix that. Even if the ErrorDocument were not to exist, it'd generate a 404 which doesn't drop the connection and we'd send the canned 404. Perhaps doing a rewrite on an error is wrong too. In fact, I'd say that the original BAD_REQUEST (400) coming from mod_rewrite should really be a 404. Problem solved. Regardless, this change must be reverted. -- justin
Re: ab with ssl for win32
> At 02:43 PM 6/20/2002, you wrote: > >Is there any planned ssl support for ab on win32? It seems like a > >trivial makefile change... > > It's already there. See the abs.dsp project. > Thanks. I was looking at ab.mak and dsp, and naturally I didn't see it there. I didn't think to open up the other makefiles, and I didn't catch the executable name change on the win_compiling directions page. --- Aryeh Katz VASCO www.vasco.com
Re: cvs commit: httpd-2.0/docs/error/include bottom.html
On Thu, Jun 20, 2002 at 03:04:07PM -0400, Joshua Slive wrote: > > The ServerTokens directive controls what is returned. So, if the > > admin doesn't want to display what version they are running, they > > only need to set that directive and that changes it for everything > > (including the Server HTTP header). -- justin > > No, that's not true at all. ServerTokens controls ONLY the HTTP header. > It does not control internal messages (ServerSignature does that), nor > does it control anything not generated directly from the apache source > code (like the internationalized error docs). Someone snuck in and moved the furniture on you while you were sleeping (i.e. follow the source). SERVER_SOFTWARE is the variable used by error/include/bottom.html. That is added in ap_add_common_vars() in server/util_script.c:268. That calls ap_get_server_version() which is the same call used to populate the Server HTTP header (see basic_http_header in http_protocol.c). That call just returns the server_version variable in server/core.c. And, the ServerTokens directive controls that value. -- justin
Re: ab with ssl for win32
At 02:43 PM 6/20/2002, you wrote: >Is there any planned ssl support for ab on win32? It seems like a trivial >makefile change... It's already there. See the abs.dsp project. Follows the same rules as mod_ssl, there must be an openssl tree within httpd-2.0/srclib/, it could be a junction or the tree itself. See http://httpd.apache.org/docs-2.0/platform/win_compiling.html Bill
Re: cvs commit: httpd-2.0/modules/http http_request.c
Justin Erenkrantz wrote: > > On Thu, Jun 20, 2002 at 03:41:51PM -0400, Cliff Woolley wrote: > > > > Somebody remind me why that ap_status_drops_conn call was added in the > > first place? It was a recent change, and seemed important at the time. > > Woah, woah, woah. Please revert. > > If the status results in a dropped connection, we can't read the > body because that status code means we don't trust the input. This > also means that the r->status code can not be the recursive code (which > doesn't result in a dropped connection), but must remain the error > that we just got in ap_die, so that we know that we're not supposed > to read the body. This is central to our 413 fixes. We cannot tolerate infinite recursion if an ErrorDocument gets an error. The if statement I changed is how we detect this sort of recursive error. Please take a look at the backtrace I posted to [EMAIL PROTECTED], under the subject "2.0.38-39 lockup problem ?". If we need to prevent reading the body for certain types of errors, we can't do it at the expense of loosing our recursive error protection. Greg
Re: cvs commit: httpd-2.0/modules/http http_request.c
On Thu, Jun 20, 2002 at 03:41:51PM -0400, Cliff Woolley wrote: > > Somebody remind me why that ap_status_drops_conn call was added in the > first place? It was a recent change, and seemed important at the time. Woah, woah, woah. Please revert. If the status results in a dropped connection, we can't read the body because that status code means we don't trust the input. This also means that the r->status code can not be the recursive code (which doesn't result in a dropped connection), but must remain the error that we just got in ap_die, so that we know that we're not supposed to read the body. This is central to our 413 fixes. Please find another way to fix this. -- justin
Re: cvs commit: httpd-2.0/modules/http http_request.c
On Thu, Jun 20, 2002 at 03:41:51PM -0400, Cliff Woolley wrote: > > Somebody remind me why that ap_status_drops_conn call was added in the > first place? It was a recent change, and seemed important at the time. I think it was so that we can drop the connection on certain error conditions immediately upon detecting the condition, instead of getting back to a blocking read from the socket and hanging on bogus input data. -aaron
Re: cvs commit: httpd-2.0/modules/http http_request.c
Somebody remind me why that ap_status_drops_conn call was added in the
first place? It was a recent change, and seemed important at the time.
--Cliff
On 20 Jun 2002 [EMAIL PROTECTED] wrote:
> gregames2002/06/20 12:34:29
>
> Modified:modules/http http_request.c
> Log:
> prevent infinite recursion if an ErrorDocument gets an error
>
> Reported by: Colm MacCrthaigh <[EMAIL PROTECTED]>
>
> Revision ChangesPath
> 1.148 +1 -1 httpd-2.0/modules/http/http_request.c
>
> Index: http_request.c
> ===
> RCS file: /home/cvs/httpd-2.0/modules/http/http_request.c,v
> retrieving revision 1.147
> retrieving revision 1.148
> diff -u -r1.147 -r1.148
> --- http_request.c 10 Jun 2002 22:02:57 - 1.147
> +++ http_request.c 20 Jun 2002 19:34:28 - 1.148
> @@ -117,7 +117,7 @@
> * error condition, we just report on the original error, and give up on
> * any attempt to handle the other thing "intelligently"...
> */
> -if (r->status != HTTP_OK && !ap_status_drops_connection(type)) {
> +if (r->status != HTTP_OK) {
>recursive_error = type;
>
>while (r->prev && (r->prev->status != HTTP_OK))
>
>
>
>
Re: 2.0.38-39 lockup problem ?
Colm MacCárthaigh wrote:
> also; anyone looking to replicate, I can produce it from a vanilla
> install by adding:
>
> RewriteCond %{HTTP_HOST}!monkey$[NC]
> RewriteRule ^(.+)$ banana
>
> at the bottom of the standard httpd.conf , a request with a host
> header anything other than monkey will hang the server. I've
> just rebuilt 2.0.36 and tested against the same vailla config
> and it doesnt happen.
OK, with this config I can easily duplicate the problem on .39 but not .36.
ap_die lost its recursive error defense mechanism.
We get there because mod_rewrite sees that there is a rule that maps any uri
(including the error document uri) to "banana", then calls
ap_os_is_path_absolute("banana"). It isn't absolute, so mod_rewrite sets a 400
error and bails. In .36, the brower gets the canned error strings that
indicates recursive 400 errors. In .39, we get:
#0 ap_die (type=400, r=0x860ddb8) at http_request.c:130
#1 0x08066d59 in ap_internal_redirect (
new_uri=0x80e36c0 "/error/HTTP_BAD_REQUEST.html.var", r=0x85e2d10)
at http_request.c:482
#2 0x08066675 in ap_die (type=400, r=0x85e2d10) at http_request.c:187
#3 0x08066d59 in ap_internal_redirect (
new_uri=0x80e36c0 "/error/HTTP_BAD_REQUEST.html.var", r=0x85b9af8)
at http_request.c:482
#4 0x08066675 in ap_die (type=400, r=0x85b9af8) at http_request.c:187
#5 0x08066d59 in ap_internal_redirect (
new_uri=0x80e36c0 "/error/HTTP_BAD_REQUEST.html.var", r=0x858e590)
at http_request.c:482
etc etc
I just committed a fix to http_protocol.c::ap_die which backs out part of rev
1.145. This restores the recursive error protection which is pretty important
IMO. We can rework the fix to 1.145 if we need to.
Greg
ab with ssl for win32
Is there any planned ssl support for ab on win32? It seems like a trivial makefile change... --- Aryeh Katz VASCO www.vasco.com
Re: cvs commit: httpd-2.0/docs/error/include bottom.html
[Sorry, I missed this earlier.] Justin Erenkrantz wrote: > On Wed, Jun 19, 2002 at 10:25:59PM -0400, Joshua Slive wrote: > >>In any case, I have a patch ready to commit that removes Ryan's changes, >>but comments-out the internationalized error docs in the default config. >> I believe that is better than the existing setup for a variety of >>reasons, and it leaves the server string in the default setup (via the >>builtin error messages). Would that resolve your veto? > > > Why wouldn't we want to internationalize the error docs by default? Because in order to internationalize the error docs we need to turn on a bunch of complex features that aren't otherwise used in the default install. > > The ServerTokens directive controls what is returned. So, if the > admin doesn't want to display what version they are running, they > only need to set that directive and that changes it for everything > (including the Server HTTP header). -- justin No, that's not true at all. ServerTokens controls ONLY the HTTP header. It does not control internal messages (ServerSignature does that), nor does it control anything not generated directly from the apache source code (like the internationalized error docs). Joshua.
Re: Linux and the worker model
I built with the default configuration first (no mpm switch), then using the worker mpm. That was the mistake. The define for AP_MPM_USES_POD was probably still alive in my console. Building using the mpm switch for worker model first works fine. Thanks, JJ >>> [EMAIL PROTECTED] 06/20/02 11:54AM >>>They should both be there. The version in mpm_common is for MOST mpms,but worker uses a different set of functions. If you worker MPM headersare actually defining AP_MPM_USES_POD, then there is a problem with thesource. The version in CVS does not define this for worker.RyanOn Thu, 20 Jun 2002, Jean-Jacques Clar wrote:> I am building 2.0.39, but it was the same thing with 2.0.35.> > >>> [EMAIL PROTECTED] 06/20/02 10:26AM On Thu, Jun 20, 2002 at 09:09:45AM -0600, Jean-Jacques Clar wrote:> > There are errors when building 2.0.x on Linux RH7.3 with the worker> > Which version of 2.0 exactly?> > -aaron> -- ___Ryan Bloom [EMAIL PROTECTED]550 Jean StOakland CA 94610---
Re: Linux and the worker model
They should both be there. The version in mpm_common is for MOST mpms, but worker uses a different set of functions. If you worker MPM headers are actually defining AP_MPM_USES_POD, then there is a problem with the source. The version in CVS does not define this for worker. Ryan On Thu, 20 Jun 2002, Jean-Jacques Clar wrote: > I am building 2.0.39, but it was the same thing with 2.0.35. > > >>> [EMAIL PROTECTED] 06/20/02 10:26AM >>> > On Thu, Jun 20, 2002 at 09:09:45AM -0600, Jean-Jacques Clar wrote: > > There are errors when building 2.0.x on Linux RH7.3 with the worker > > Which version of 2.0 exactly? > > -aaron > -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Fwd: Re: [ANNOUNCE] Apache 2.0.39 Released
A response to our announce from the front. I don't recognize the problem, perhaps someone else will. Kevin, you may want to follow up with a bug report to http://nagoya.apache.org/bugzilla/ as we've closed down email bug reporting through bugs.apache.org. Your report is a little sparse on details, please add some specifics before filing a bug report. Bill >Date: Wed, 19 Jun 2002 15:24:16 -0600 >From: "Kevin Dahl" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> >Subject: Re: [ANNOUNCE] Apache 2.0.39 Released > >FYI.. > >Installing v2.0.39 broke my perl scripts ability to >run.(ActivePerl v5.6.1.632).uninstalling 2.0.39 and >installing 2.0.36 allowed them to work again.thought you might >want to know. > >I saw this once before with v 1.3.12 I believe..installing >1.3.14 broke the functionality and reinstalling 1.3.12 allowed them to >work againall installations after 1.3.14 worked >fine > > >K-Dee > >* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >** Kevin Dahl >** Computer Specialist >** USDA / ARS / Northern Plains Ag Research Lab >** http://www.sidney.ars.usda.gov/ >** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > >>> <[EMAIL PROTECTED]> 6/18/2002 5:53:49 PM >>> >The Apache HTTP Server Project is proud to announce the third public >release of Apache 2.0. Apache 2.0 has been running on the Apache.org >website since December of 2000 and has proven to be very reliable. > >This version of Apache is principally a security and bug fix >release. A summary of the bug fixes is given at the end of this >document. >Of particular note is that 2.0.39 addresses and fixes the issues noted >in CAN-2002-0392 (mitre.org) [CERT VU#944335] regarding a >vulnerability >in the handling of chunked transfer encoding. We would like to thank >Mark Litchfield of ngssoftware.com for discovering and reporting the >vulnerability. > >Apache 2.0 offers numerous enhancements, improvements and performance >boosts over the 1.3 codebase. The most visible and noteworthy addition >is the ability to run Apache in a hybrid thread/process mode on any >platform that supports both threads and processes. This has shown to >improve the scalability of the Apache HTTP Server significantly in >our testing. Apache 2.0 also includes support for filtered I/O. This >allows modules to modify the output of other modules before it is >sent to the client. We have also included support for IPv6 on any >platform that supports IPv6. > >This version of Apache is known to work on many versions of Unix, >BeOS, >OS/2, Windows, and Netware. Because of many of the advancements in >Apache 2.0, the initial release of Apache is expected to perform >equally >well on all supported platforms. > >There are new snapshots of the Apache httpd source available every 6 >hours from http://cvs.apache.org/snapshots/ - please download and test >if you feel brave. We don't guarantee anything except that it will >take up disk space, but if you have the time and skills, please >give it a spin on your platforms. > >Apache has been the most popular web server on the Internet since >April of 1996. The March 2002 WWW server site survey by Netcraft (see >http://www.netcraft.com/survey/) found that more web servers were >using Apache than any other software; Apache runs on more than 54% >of the web servers on the Internet. > >For more information and to download the release tarballs, please >visit http://httpd.apache.org/ > > >Changes since 2.0.36 >- > >Changes with Apache 2.0.39 > > *) Fixed a build problem in htpasswd.c on Win32. > [Guenter Knauf <[EMAIL PROTECTED]>, Cliff Woolley] > >Changes with Apache 2.0.38 > > *) Rewrite htpasswd to use APR. The removes the annoying warning >about > tmpnam being unsafe. [Ryan Bloom] > > *) We must set the MIME-type for .shtml files to text/html if we want >them > to be parsed for SSI tags. Add the config for that to the default > > config file so that it is easier to enable .shtml parsing. > [Dave Dyer <[EMAIL PROTECTED]>] > > *) Fixed a problem with 'make install' on ReliantUnix. > [Jean-frederic Clere <[EMAIL PROTECTED]>] > > *) Make the default_handler catch all requests that aren't served by > another handler. This also gets us to return a 404 if a >directory > is requested, there is no DirectoryIndex, and mod_autoindex isn't > loaded. [Justin Erenkrantz] > > *) Fixed the handling of nested if-statements in shtml files. > PR 9866 [Brian Pane] > > *) Allow 'make install DESTDIR=/path'. This allows packagers to >install > into a directory different from the one that was configured. This > > also mirrors the root= feature from 1.3. We cannot use p
Re: Linux and the worker model
I am building 2.0.39, but it was the same thing with 2.0.35.>>> [EMAIL PROTECTED] 06/20/02 10:26AM >>>On Thu, Jun 20, 2002 at 09:09:45AM -0600, Jean-Jacques Clar wrote:> There are errors when building 2.0.x on Linux RH7.3 with the workerWhich version of 2.0 exactly?-aaron
Re: Linux and the worker model
On Thu, Jun 20, 2002 at 09:09:45AM -0600, Jean-Jacques Clar wrote: > There are errors when building 2.0.x on Linux RH7.3 with the worker Which version of 2.0 exactly? -aaron
Re: cvs commit: httpd-2.0/docs/error/include bottom.html
On Wed, Jun 19, 2002 at 02:20:04PM -0700, Ryan Bloom wrote: > > I'm sorry to have to revisit this, but I'm going to have to -1 this > > whole thing. I don't want to have to go and enable all of my error > > docs just because some admins believe it exposes them to risk, > > which of course is total bunk. > > This argument is complete bunk. The problem is simple. We provide a > directive that disables showing server information in the error log. > With the default for our custom logs being to show that information, it > is completely non-intuitive that if I disable the feature in the config > file the error docs will ignore that config. Then tie it to the directive, and don't disable it by default. Having to deal with this in two places makes no sense. That's what I'm vetoing. Although I'm opposed to it, I haven't vetoed the directive itself. Having the option to turn it off is at least a compromise. I tend to think that by even having the option we are giving some hope to an administrator that by turning off the verions he is somehow protecting himself. > Simply by principle of least astonishment, the default should be the > most restrictive, so that people who decide to be the most restrictive > won't have to go changing things. I don't know what you mean by restrictive. Apache should be safe to run with the default configurations. Having a server string does not in any known way increase risk. > I would also remind you that there are people on this list who run major > servers who _don't_ give out version information. That may be because > their company demands it, or it may be because they believe it is more > secure. It really doesn't matter. Irrelevent. These people have the ability to remove the server string from their server by mere fact that they have the source. We are doing them a favor by simply making it a runtime option. > Having the information in the error pages by default is bogus. Either > add another variable, or leave it out. Adding it back in completely is > completely wrong. And I'm saying tie it to the directive or don't change it from how it's been for a long long time. -aaron
