Explicit "Host: domain.com:80" port may conflict with reasonable Host-based redirection rules
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Sam2304
	Sep 5 2016, 9:19 AM

Description

Hi Folks,

I updated both my install and my local arcanist repo's to the head of stable today and am now seeing cURL/47 errors on any arcanist commands, I wonder if anyone can help?

Running the standard connection check works fine, note I have phabricator setup to run over port 2222 with user git, which has been working flawlessly:

$ echo {} | ssh -p 2222 git@phabricator.local conduit user.whoami
{"result":{"phid":"PHID-USER-blahblah","userName":"Sam","realName":"Sam","image":"http:\/\/phabricator.local\/file\/data\/g57z5iku5s2x4rpi7k6r\/PHID-FILE-xhdrpuvh5lbu7tmkfso5\/profile","uri":"http:\/\/phabricator.local\/p\/Sam\/","roles":["admin","verified","approved","activated"],"primaryEmail":"Sam@blahblah"},"error_code":null,"error_info":null}

However running the arc equivalent fails:

$ arc call-conduit user.whoami
Exception
[cURL/47] (http://phabricator.local/api/user.whoami) <CURLE_TOO_MANY_REDIRECTS> The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 47) on the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLETOOMANYREDIRECTS
(Run with `--trace` for a full exception trace.)

Is there some expected behavior change associated with one of the last cuts to stable? I believe I pulled in the last two weeks changes today. My Arc Version:

$ arc version
arcanist 9e82ef979e8148c43b9b8439025d505b1219e213 (25 Aug 2016)
libphutil c8b76485ef845a40af96c132c16e0f28f145bdd2 (2 Sep 2016)
Phabricator Version:

Version Information	
phabricator ca30df847e4e99aec46dd97c7bd9b4f7d8542cab  (Sat, Sep 3)
arcanist    10e5194752901959507223c01e0878e6b8312cc5  (Sat, Aug 27)
phutil      f748cdbc8d08175375f4c4c87fc679de3145c620  (Sat, Sep 3)
sprint      569b469197f988d8d577610dfd6f7d37b87bf19b  (Jul 10 2016)

Looking in the apache access log I see a lot of these when I run the above arc calls:

"POST /api/user.whoami HTTP/1.1" 302 587 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 655 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 723 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 791 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 859 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 927 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 995 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1063 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1131 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1199 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1267 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1335 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1403 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1471 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1539 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1607 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1675 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1743 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1811 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1880 "-" "-"
"POST /api/user.whoami?__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami&__path__=%2fapi%2fuser%2ewhoami HTTP/1.1" 302 1948 "-" "-"

Note that I see a similar error pattern using any other arc command like arc which, arc diff etc. which was working fine last week, prior to upgrade...

Interestingly I noticed my local arcanist was tracking master not local, adjusting and the error persists, arc version now reads:

arc version
arcanist 10e5194752901959507223c01e0878e6b8312cc5 (27 Aug 2016)
libphutil f748cdbc8d08175375f4c4c87fc679de3145c620 (3 Sep 2016)

Curl Version in case thats useful:

curl --version
curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets

Revisions and Commits

rPHU libphutil
	D16491	rPHUc14343ee620e (stable) Don't include default port (80, 443) in "Host:" headers from Conduit
	D16491	rPHU97f05269fdb1 Don't include default port (80, 443) in "Host:" headers from Conduit

Related Objects

Mentioned In: Z1336: General Chat
Mentioned Here: T11553: Add various "make an HTTP call" setup checks, and run them in parallel
rPHU491ebc74d816: Properly Set Host Header in Conduit Client

Event Timeline

Sam2304 created this task.Sep 5 2016, 9:19 AM

Sam2304 mentioned this in Z1336: General Chat.

Further testing, the standard curl request seems to be fine:

curl http://phabricator.local/api/user.whoami \
>     -d api.token=cli-37au4odrzomsk54zbnolivacknw3
{"result":{"phid":"PHID-USER-omtmnetw55dqsgt576g7","userName":"Sam","realName":"Sam","image":"http:\/\/phabricator.local\/file\/data\/g57z5iku5s2x4rpi7k6r\/PHID-FILE-xhdrpuvh5lbu7tmkfso5\/profile","uri":"http:\/\/phabricator.local\/p\/Sam\/","roles":["admin","verified","approved","activated"],"primaryEmail":"Sam@blahblah.com"},"error_code":null,"error_info":null}

It also works from the web-conduit application in phabricator http://phabricator.local/api/user.whoami, but it fails from arc:

echo '{}' | arc call-conduit --conduit-uri http://phabricator.local/ --conduit-token cli-37au4odrzomsk54zbnolivacknw3 user.whoami
Exception
[cURL/47] (http://phabricator.local/api/user.whoami) <CURLE_TOO_MANY_REDIRECTS> The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 47) on the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLETOOMANYREDIRECTS
(Run with `--trace` for a full exception trace.)

Weird.

Sam2304 updated the task description. (Show Details)Sep 5 2016, 9:43 AM

What do you get if you run the same command with --trace flag ?

Interesting:

echo '{}' | arc --trace call-conduit --conduit-uri http://phabricator.local/ --conduit-token cli-37au4odrzomsk54zbnolivacknw3 user.whoami
 ARGV  '/home/sam/bin/phabricator-tools/arcanist/bin/../scripts/arcanist.php' '--trace' 'call-conduit' '--conduit-uri' 'http://phabricator.local/' '--conduit-token' 'cli-37au4odrzomsk54zbnolivacknw3' 'user.whoami'
 LOAD  Loaded "phutil" from "/home/sam/bin/phabricator-tools/libphutil/src".
 LOAD  Loaded "arcanist" from "/home/sam/bin/phabricator-tools/arcanist/src".
Config: Reading user configuration file "/home/sam/.arcrc"...
Config: Did not find system configuration at "/etc/arcconfig".
Working Copy: Reading .arcconfig from "/home/sam/Coding/UMC/Src/.arcconfig".
Working Copy: Path "/home/sam/Coding/UMC/Src" is part of `git` working copy "/home/sam/Coding/UMC/Src".
Working Copy: Project root is at "/home/sam/Coding/UMC/Src".
Config: Did not find local configuration at "/home/sam/Coding/UMC/Src/.git/arc/config".
>>> [0] <conduit> user.whoami() <bytes = 117>
>>> [1] <http> http://phabricator.local/api/user.whoami
<<< [1] <http> 195,683 us
<<< [0] <conduit> 195,955 us

[2016-09-05 09:59:06] EXCEPTION: (ConduitClientException) ERR-INVALID-SESSION: Session key is not present. at [<phutil>/src/conduit/ConduitFuture.php:58]
arcanist(head=stable, ref.master=9e82ef979e81, ref.stable=10e519475290), phutil(head=stable, ref.master=c8b76485ef84, ref.stable=f748cdbc8d08)
  #0 ConduitFuture::didReceiveResult(array) called at [<phutil>/src/future/FutureProxy.php:58]
  #1 FutureProxy::getResult() called at [<phutil>/src/future/FutureProxy.php:35]
  #2 FutureProxy::resolve() called at [<phutil>/src/conduit/ConduitClient.php:64]
  #3 ConduitClient::callMethodSynchronous(string, array) called at [<arcanist>/src/workflow/ArcanistWorkflow.php:332]
  #4 ArcanistWorkflow::authenticateConduit() called at [<arcanist>/scripts/arcanist.php:356]

I wasn't getting that a moment ago but rebooted the application (apache restart) to see if that would clear things, looks like its complicated matters...

Running arc which --trace:

arc which --trace
 ARGV  '/home/sam/bin/phabricator-tools/arcanist/bin/../scripts/arcanist.php' 'which' '--trace'
 LOAD  Loaded "phutil" from "/home/sam/bin/phabricator-tools/libphutil/src".
 LOAD  Loaded "arcanist" from "/home/sam/bin/phabricator-tools/arcanist/src".
Config: Reading user configuration file "/home/sam/.arcrc"...
Config: Did not find system configuration at "/etc/arcconfig".
Working Copy: Reading .arcconfig from "/home/sam/Coding/UMC/Src/.arcconfig".
Working Copy: Path "/home/sam/Coding/UMC/Src" is part of `git` working copy "/home/sam/Coding/UMC/Src".
Working Copy: Project root is at "/home/sam/Coding/UMC/Src".
Config: Did not find local configuration at "/home/sam/Coding/UMC/Src/.git/arc/config".
>>> [0] <conduit> user.whoami() <bytes = 117>
>>> [1] <http> http://phabricator.pt.local/api/user.whoami
<<< [1] <http> 17,662 us
<<< [0] <conduit> 17,935 us

[2016-09-05 10:00:30] EXCEPTION: (HTTPFutureCURLResponseStatus) [cURL/47] (http://phabricator.pt.local/api/user.whoami) <CURLE_TOO_MANY_REDIRECTS> The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 47) on the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLETOOMANYREDIRECTS at [<phutil>/src/future/http/HTTPSFuture.php:408]
arcanist(head=stable, ref.master=9e82ef979e81, ref.stable=10e519475290), phutil(head=stable, ref.master=c8b76485ef84, ref.stable=f748cdbc8d08)
  #0 HTTPSFuture::isReady() called at [<phutil>/src/future/Future.php:37]
  #1 Future::resolve(NULL) called at [<phutil>/src/future/FutureProxy.php:34]
  #2 FutureProxy::resolve() called at [<phutil>/src/conduit/ConduitClient.php:64]
  #3 ConduitClient::callMethodSynchronous(string, array) called at [<arcanist>/src/workflow/ArcanistWorkflow.php:332]
  #4 ArcanistWorkflow::authenticateConduit() called at [<arcanist>/scripts/arcanist.php:356]

Oddly, running the curl command still works as previously captured, with the same Token... :/

I can replicate the cURL error from a configured repository, its the same trace as that of the arc which command above:

[2016-09-05 10:06:49] EXCEPTION: (HTTPFutureCURLResponseStatus) [cURL/47] (http://phabricator.pt.local/api/user.whoami) <CURLE_TOO_MANY_REDIRECTS> The cURL library raised an error while making a request. You may be able to find more information about this error (error code: 47) on the cURL site: http://curl.haxx.se/libcurl/c/libcurl-errors.html#CURLETOOMANYREDIRECTS at [<phutil>/src/future/http/HTTPSFuture.php:408]
arcanist(head=stable, ref.master=9e82ef979e81, ref.stable=10e519475290), phutil(head=stable, ref.master=c8b76485ef84, ref.stable=f748cdbc8d08)
  #0 HTTPSFuture::isReady() called at [<phutil>/src/future/Future.php:37]
  #1 Future::resolve(NULL) called at [<phutil>/src/future/FutureProxy.php:34]
  #2 FutureProxy::resolve() called at [<phutil>/src/conduit/ConduitClient.php:64]
  #3 ConduitClient::callMethodSynchronous(string, array) called at [<arcanist>/src/workflow/ArcanistWorkflow.php:332]
  #4 ArcanistWorkflow::authenticateConduit() called at [<arcanist>/scripts/arcanist.php:356]

If you revert rPHU491ebc74d816dbe2fc8bbbbc992e8a14f8c613be in libphutil, does that fix it?

(Change getHostString() back to getHost() in src/conduit/ConduitClient.php in libphutil, near line 147.)

Spot on! reverting that change on my arcanist client resolved any issues completely.

Prior to that change, we did not send ports in Host: headers in requests.

After that change, we always send ports in Host: headers. Presumably, your server is configured to redirect domain.com:80 to domain.com (or 443, if using HTTPS).

I think this configuration is probably at least arguably incorrect according to the spec, but our behavior is a bit unusual and different from what browsers usually do, which is to omit 80 for HTTP and 443 for HTTPS, and only provide a port if it is a nonstandard port.

I'll change our behavior to match browser behavior, since I think this is likely easier for everyone in the long run than trying to detect and correct this, even if everyone agrees that redirecting domain.com:80 to domain.com is incorrect.

I had to look that up its been so long since I fiddled with the server hosting.

I have the following Apache config:

<VirtualHost *:80>
  <If "%{HTTP_HOST} != 'phabricator.pt.local'">
        Redirect "/" "http://phabricator.pt.local/"
  </If>

  # Change this to the domain which points to your host.
  ServerName phabricator.pt.local

  # Change this to the path where you put 'phabricator' when you checked it
  # out from GitHub when following the Installation Guide.
  #
  # Make sure you include "/webroot" at the end!
  DocumentRoot /usr/share/phabricator/phabricator/webroot

  RewriteEngine on
  RewriteRule ^/rsrc/(.*)     -                       [L,QSA]
  RewriteRule ^/favicon.ico   -                       [L,QSA]
  RewriteRule ^(.*)$          /index.php?__path__=$1  [B,L,QSA]
  LimitRequestBody 33554432
</VirtualHost>

<Directory "/usr/share/phabricator/phabricator/webroot">
  Require all granted
</Directory>

<Directory "/usr/share/phabricator/phabricator-extension-Sprint">
  Require all granted
</Directory>

I might get around to trying to host it with nginx, as I'm more familiar with that nowadays...

I'll experiment with the redirect stuff (I don't remember why its there at all, someone kept trying to use the IP address which doesn't work or some such) and post back here what I find.

Thanks again for the lightspeed response. :)

This is probably the issue:

<If "%{HTTP_HOST} != 'phabricator.pt.local'">
      Redirect "/" "http://phabricator.pt.local/"
</If>

The host will be phabricator.pt.local:80 after the Conduit change. I think your rewrite rule is "wrong" (it's valid for us to send :80 according to the spec), but our behavior is definitely surprising/unexpected and there's no real reason for it.

(You should probably also remove the phabricator-extension-Sprint "Directory" entry. This should be unnecessary at best, and insecure at worst.)

Confirmed, removing that redirect at the top of my apache config. also resolves the problem without changing the upstream.

I think its probably fine to leave your application logic as is, if users want to fiddle with re-directs, thats up to them but I'd just have to be a bit smarter about how I go about it.

If I recall correctly that redirect got in there in an attempt to resolve some issue I was having internally with a team on a VPN not getting DNS resolution on the system, but we resolved it by fixing the VPN rather than fiddling here, I guess I forgot to remove it afterwards...

Thanks for the tip re the Sprint Extension as well, I will fiddle with that whilst I am here. :)

Adjusting the redirect to use `phabricator.pt.local:80' also fixes the issue, though I have removed it as I don't think anyone here still tries to use an IP...

If there is any documentation anywhere about proxying Phabricator (If I remember correctly you discourage it), it might be worth putting a note in about inclusion of the port in the requests but I don't see any reason you'd need to change the application logic.

Better to get silly buggers like me to configure my server properly... ;)

I'd mark this resolved if I could.

Thank you once again for your help and advice, its much appreciated.

Even though I think there's a good technical argument that our behavior is reasonable, the lifetime support cost of changing the application logic to be more similar to what browsers do is almost probably lower than the lifetime support cost of documenting this explicit port behavior, since there will be 100 more people who try the same thing in the future and maybe 5 of them will read the docs if we're lucky.

This also isn't something we can easily detect automatically. In theory, we could try to detect it via mechanisms like T11553, but it would be hard to get a conclusive positive test. That test would also be more complex than just changing the application behavior.

epriestley added a revision: D16491: Don't include default port (80, 443) in "Host:" headers from Conduit.Sep 5 2016, 1:54 PM

epriestley renamed this task from Arcanist calls return cURL error 47 - Too Many Redirects to Explicit "Host: domain.com:80" port may conflict with reasonable Host-based redirection rules.Sep 5 2016, 1:57 PM

epriestley claimed this task.

epriestley triaged this task as Normal priority.

epriestley closed this task as Resolved by committing rPHU97f05269fdb1: Don't include default port (80, 443) in "Host:" headers from Conduit.Sep 5 2016, 2:50 PM

epriestley added a commit: rPHU97f05269fdb1: Don't include default port (80, 443) in "Host:" headers from Conduit.

epriestley added a commit: rPHUc14343ee620e: (stable) Don't include default port (80, 443) in "Host:" headers from Conduit.

This should now be fixed in HEAD of master. I've also cherry-picked it to stable.

(If you update, the older version of the redirect should work again.)

Let us know if you run into anything else.

@epriestley You (and your team) are freaking epic. I owe you a beer (or several). If you're ever near Basingstoke, UK drop me a line!

michaeljs1990 added a subscriber: michaeljs1990.Sep 5 2016, 9:17 PM

Explicit "Host: domain.com:80" port may conflict with reasonable Host-based redirection rulesClosed, ResolvedPublicActions

Description

Revisions and Commits

Related Objects

Event Timeline

Explicit "Host: domain.com:80" port may conflict with reasonable Host-based redirection rules
Closed, ResolvedPublic
Actions