Received: (qmail 21849 invoked by uid 2012); 19 Oct 1998 17:26:11 -0000 Message-Id: <19981019172611.21848.qmail@hyperreal.org> Date: 19 Oct 1998 17:26:11 -0000 From: Randy Weinstein Reply-To: rw263@is7.NYU.EDU To: apbugs@hyperreal.org Subject: Inability to customize error 500 X-Send-Pr-Version: 3.2 >Number: 3244 >Category: config >Synopsis: Inability to customize error 500 >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: closed >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Mon Oct 19 10:30:00 PDT 1998 >Last-Modified: Mon Oct 19 11:40:01 PDT 1998 >Originator: rw263@is7.NYU.EDU >Organization: >Release: 1.3.3 >Environment: N/A >Description: If in an htaccess file you have the line: ErrorDocument 403 /Errors/Forbidden.html And in a subdirectory of where that htaccess file is present, you create a directory that is chmod'd such that it is not world read (example: chmod 700), the ErrorDocument 403 is NOT read in and the default is used. PR #2409 disregards this example saying, "Submitter says ... isn't a problem after all", but it is. Didn't want this case to be forgotten about. >How-To-Repeat: create an htaccess file with the line: ErrorDocument 403 "Customized Forbidden Error Message then create a subdirectory under that parent directory that contains that htaccess file and chmod the directory to something like 700 When that directory is tried to access from the web, the default standard forbidden error message is used, not the custom one from ErrorDocument >Fix: Similar to the fix in PR#2409, they are quite similar, I am unable to test if the fixed PR Report #2409, will fix this PR Report as well. >Audit-Trail: State-Changed-From-To: open-closed State-Changed-By: marc State-Changed-When: Mon Oct 19 10:48:05 PDT 1998 State-Changed-Why: First, it isn't necessary to open a new PR if you simply wish to ask that a previous one be reopened. Second, I am confused by your description of the problem as "Inability to customize error 500". You were already told that was fixed. Third, the problem you describe with 403s is essentially the same as the previous one. It appears to have been fixed by the commit that fixes your previous report. Thanks. From: Marc Slemko To: Randy Jae Weinstein Cc: Apache bugs database Subject: Re: config/3244: Inability to customize error 500 Date: Mon, 19 Oct 1998 11:27:34 -0700 (PDT) On Mon, 19 Oct 1998, Randy Jae Weinstein wrote: > Sorry about opening another report, I was unaware you could add to a > closed report. I guess you can though. > > As for the subject, it should have read "Inability to customize error > 403", my mistake (kinda tired here). > > This report is different. Let me explain. Error 500 inability to > customize was do to an error in the htaccess file of a subdirectory. If > the child subdir's htaccess had an error than the standard error message > would be shown. > > The Error 403 has to do with a directory being not set as world read (done > on purpose), and then having a default error message instead of the custom > error message. The 500 Error was fixed do to a change in the later > htaccess file (way it was readin/parsed, I assume), where as the 403 deals > with a directory parsing getting halted. If you had read the response to your previous PR, you would know that the real problem is that when doing merging of directives as walking down a tree, the merge was not "completed" until the entire tree was read. This means that if it aborted in the middle, due to an invalid htaccess file entry, a directory it couldn't read, etc. then the settings higher up the tree wouldn't be used. That was fixed. > > > If indeed the 500 error fix corrects the 403 error fix, then by all means > delete this PR, however I don't think that is the case. > > -Cheers, > RJW > > >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ] [If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request ] [from a developer. ] [Reply only with text; DO NOT SEND ATTACHMENTS! ]