Bug 1485966

Summary: incorrect Content-Type logged for mod_proxy_fcgi if it is actually unset
Product: Red Hat Enterprise Linux 7 Reporter: Rainer Canavan <rainer.canavan+rhelbugs>
Component: httpdAssignee: LuboŇ° Uhliarik <luhliari>
Status: CLOSED WONTFIX QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.3CC: bnater, jorton, luhliari
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: All   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-01-16 10:56:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Rainer Canavan 2017-08-28 15:00:52 UTC
Description of problem:

If a request is handled by mod_proxy_fcgi and an empty response with code 304 and no Content-Type Header is returned, the access log will expand %{Content-Encoding}o to a Content-Type that is derived from the suffix of the proxy location instead of leaving it empty (and log "-"). This has been fixed in newer versions of httpd. The offending code may be in find_ct() in modules/http/mod_mime.c

How reproducible:

run httpd with 

RewriteRule ^(\/\/?[^/]+)(/.*)? fcgi:// [P,L]

LogFormat "%a %v:%p %l %u %t %{UNIQUE_ID}e \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" host:\"%{host}i\" mime:\"%{Content-Type}o\"" accesslog
CustomLog /tmp/access_log accesslog

and php-fpm with 

listen =

and script.uvvg


Header('Last-Modified: Thu, 25 Aug 2016 13:07:23 GMT');
    error_log('304 ims: '.$_SERVER['HTTP_IF_MODIFIED_SINCE']);
    Header('Status: 304');

Header('Content-Type: image/png');

Steps to Reproduce:

1. curl -vH 'If-Modified-Since: Thu, 25 Aug 2016 13:07:23 GMT' http://host/anything

Actual results:

access.log contains


Expected results:

access.log contains


Comment 2 Joe Orton 2017-10-09 12:19:46 UTC
Thank you for taking the time to report this issue to us. We appreciate the feedback and use reports such as this one to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness or suitability of a resolution.

If this issue is critical or in any way time sensitive, please raise a ticket through the regular Red Hat support channels to ensure it receives the proper attention and prioritization to assure a timely resolution. 

For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/en/services/support

Comment 7 RHEL Program Management 2020-01-16 10:56:54 UTC
Development Management has reviewed and declined this request. You may appeal this decision by using your Red Hat support channels, who will make certain  the issue receives the proper prioritization with product and development management.