Bug 1224763 - wrong default port for fcgi
Summary: wrong default port for fcgi
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Software Collections
Classification: Red Hat
Component: httpd
Version: httpd24
Hardware: All
OS: Unspecified
unspecified
high
Target Milestone: alpha
: 2.4
Assignee: Luboš Uhliarik ✈
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 1224775
TreeView+ depends on / blocked
 
Reported: 2015-05-25 14:49 UTC by Ondřej Pták
Modified: 2017-01-25 12:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1224775 (view as bug list)
Environment:
Last Closed: 2017-01-25 12:07:32 UTC


Attachments (Terms of Use)

Description Ondřej Pták 2015-05-25 14:49:24 UTC
Description of problem:
When using mod_proxy with php-fpm and, httpd use port 8000 instead of 9000 as default for fcgi protocol.
This is hardcoded in: httpd-2.4.12/modules/proxy/proxy_util.c

Version-Release number of selected component (if applicable):
httpd24-httpd-2.4.12-6

How reproducible:
always

Steps to Reproduce:
1. configure mod_proxy to use fcgi://localhost/path
2. download page
3. ...or use linked test

Actual results:
http code 503

Expected results:
http code 200

Additional info:

error_log:
[Mon May 25 10:41:38.990807 2015] [proxy:error] [pid 1335] (111)Connection refused: AH00957: FCGI: attempt to connect to 127.0.0.1:8000 (*) failed
[Mon May 25 10:41:38.990886 2015] [proxy_fcgi:error] [pid 1335] [client ::1:53653] AH01079: failed to make connection to backend: localhost

Comment 1 Jan Kaluža 2016-02-11 10:26:57 UTC
There was no consensus upstream whether we should change the default port and what should it be. We should not do changes like that without the upstream first. Therefore we won't include this bug in rhscl-2.2.0.

Comment 2 Joe Orton 2017-01-25 12:07:32 UTC
Upstream still use port 8000 as the default port mapping for fcgi://.  Changing the implicit default is potentially a backwards compat break so we'd need very good motivation to change it in RHSCL.  

Plus both 8000 and 9000 are IETF reserved ports... unlikely we'll patch anything in here.


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