Bug 498385 - httpd incorrectly returns lower level return code (70007 status code is not RFC)
httpd incorrectly returns lower level return code (70007 status code is not RFC)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: httpd (Show other bugs)
4.7
All Linux
medium Severity medium
: rc
: ---
Assigned To: Joe Orton
BaseOS QE
:
Depends On: 498170
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-30 04:44 EDT by Martin Poole
Modified: 2010-10-26 15:27 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 498170
Environment:
Last Closed: 2010-10-26 15:27:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Poole 2009-04-30 04:44:50 EDT
+++ This bug was initially created as a clone of Bug #498170 +++

Escalated to Bugzilla from IssueTracker

--- Additional comment from tao@redhat.com on 2009-04-29 05:24:34 EDT ---

This question relates to bz #484772 (<https://bugzilla.redhat.com/show_bug.cgi?id=484772>)

ssl_access_log on our satellite shows the improper 70007 status codes (codes are regulated by RFC, supposed to be 3 digits). The bz above shows:
  Status:  	 CLOSED INSUFFICIENT_DATA 

Is there some other bz or something in the works to correct this?


-----------
FWIW -- I can somewhat randomly cause the status by POSTing a file to a CGI handler. This handler is a minor variation on the upload_file.cgi that ships with the satellite product.
This event sent from IssueTracker by mpoole  [Support Engineering Group]
 issue 282716

--- Additional comment from tao@redhat.com on 2009-04-29 05:24:36 EDT ---

# Provide time and date of the problem

06/Apr/2009:07:14:48

# Indicate the platform(s) (architectures) the problem is being reported
against.

i686

# Provide clear and concise problem description as it is understood at the
time of escalation

    * Observed behavior

Customers finding HTTP 70007 errors in the logs.  Just wondering if this
is a reason for concern or just incorrectly logged status codes. 


Satellite info:

rhns-5.2.0-16.el5     

httpd-2.2.3-11.el5_2.4 


    * Desired behavior 

No errors

# State specific action requested of SEG

Please help to troubleshoot

# State whether or not a defect in the product is suspected

    * Provide Bugzilla if one already exists 


Unable to find anything in fulltext or IT searches. 

however found the following info on http errata

https://bugzilla.redhat.com/show_bug.cgi?id=197915

BUG 197915 -  incorrectly logs status code as 70007 - default handler
returns output filter apr_status_t value




Issue escalated to Support Engineering Group by: rmunilla.
Internal Status set to 'Waiting on SEG'

This event sent from IssueTracker by mpoole  [Support Engineering Group]
 issue 282716

--- Additional comment from mpoole@redhat.com on 2009-04-29 05:30:46 EDT ---

This is specifically another variation of upstream 

https://issues.apache.org/bugzilla/show_bug.cgi?id=31759

We have in place the initial fix which covers the return path via server/core.c but as noted in https://issues.apache.org/bugzilla/show_bug.cgi?id=31759#c41 and https://issues.apache.org/bugzilla/show_bug.cgi?id=31759#c44  this can occur in other handlers as well.

Simplest fix seems to be the generic fixup referenced in https://issues.apache.org/bugzilla/show_bug.cgi?id=31759#c46 namely the patches

  http://svn.apache.org/viewvc?view=rev&revision=448711
  http://svn.apache.org/viewvc?view=rev&revision=450808

Note You need to log in before you can comment on or make changes to this bug.