Message-ID: <XFMail.980525112746.sfx@unix-ag.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.LNX.3.96dg4.980525002925.27195X-100000@twinlark.arctic.org>
Date: Mon, 25 May 1998 11:27:46 +0200 (CEST)
Organization: German Unix-AG Association
From: Lars Eilebrecht <Lars.Eilebrecht@unix-ag.org>
To: new-httpd@apache.org
Subject: Re: [PATCH] PR#1031 using a type map as a custom error document
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

According to Dean Gaudet:

>  Hey can you explain why you're using r->no_local_copy?  I'm confused... 
>  Actually I think I'm just confused because r->no_local_copy appears to
>  be true iff this expression is true:
>  
>      r->status != HTTP_OK && !is_initial_req(r)

I know that r->no_local_copy has a different meaning, but I used
it as an indicator for a custom response internal redirect,
because it is set in ap_die() before ap_internal_redirect(custom_response,r) is
called.
I wasn't sure if using is_initial_req(r) is a good thing, because this
may break things when we are processing an internal redirect, but
are not trying to build a custom response.
But maybe I'm just missing something.
  
[...]
>  ... I'd say that the correct fix is to remove the r->status test from
>  read_type_map and push it into read_types_multi, which is the only caller
>  that needs the security protection.  When read_type_map is called by
>  handle_map_file() the security protection has already been taken care of.

Yes, that seems to be the best fix.


ciao...
-- 
Lars Eilebrecht                            - If you can read this...
sfx@unix-ag.org                  - don't you think you're a wee bit too close?
http://www.home.unix-ag.org/sfx/