$config->urls->httpRoot via the command line

[adrian]

Hey guys,

I haven't come across this before. I'm in a rush but didn't want to forget to ask / report this which seems weird to me.

If you check the following via the http it returns the correct url

$config->urls->httpRoot

but if you do it via CLI then it returns the first entry in your $config->httpHosts array and gives http, rather than https. In my case I had the "dev" subdomain listed first which meant I was always getting http://dev.mydomain.com instead of https://mydomain.com

Not sure if this is a bug or not, but definitely something to be aware of if you are using a service from a cronjob and you are using this to send a url for a webhook return or something along those lines.

 

[elabx]

I can't teven find where that is defined in the source code haha I'd guess some $_SERVER value is not populated? That's what I hoped to find out searching:

https://github.com/processwire/processwire/search?q=httpRoot&unscoped_q=httpRoot

[Robin S]

35 minutes ago, adrian said:

If you check the following via the http it returns the correct url

$config->urls->httpRoot

but if you do it via CLI then it returns the first entry in your $config->httpHosts array and gives http, rather than https.

That does make some sense to me, because httpRoot is not a setting that is defined anywhere but more like "given the way you are accessing this website right now, this is the root URL". Imagine a site that had several domains that are valid to access the site at, or a site where both HTTP and HTTPS protocols are allowed without redirect (lets disregard the SEO implications of all of this). The httpRoot would be expected to change depending on the domain/protocol you are accessing the site at.

If you are using the CLI then PW doesn't have a protocol or domain to refer to so it just gives you the first allowed httpHost (rather than giving you nothing which would arguably be worse). This is how I imagine the thinking goes - I haven't looked at the code.

[adrian]

Hey @Robin S - I agree with your analysis for sure, but I am not sure that returning the first item in that array is necessarily very helpful. I think I'd rather an error telling me that it can't determine the http root so I remember that I need to hardcode it myself. Perhaps if we could force it to return https then the first item in the array might be ok, but given that every site should now be https and not http, I think the current behavior is detrimental.

[Robin S]

41 minutes ago, adrian said:

I think I'd rather an error telling me that it can't determine the http root

Yeah, I think you're right that this would be better.

[arjen]

7 hours ago, adrian said:

I am not sure that returning the first item in that array is necessarily very helpful.

+1

[Robin S]

@adrian, did you notice this snippet from Ryan in the issues repo?

if(!isset($_SERVER['HTTP_HOST'])) {
  // likely running in CLI mode
  $config->httpHost = 'examplesite.ru';
} else if(preg_match('/^[a-z]{3,20}\.examplesite\.ru$/i', $_SERVER['HTTP_HOST'])) {
  // host name matches abc.examplesite.ru where abc is between 3 to 20 a-z characters
  $config->httpHost = strtolower($_SERVER['HTTP_HOST']);
} else {
  // fallback if host does not match expected regex
  $config->httpHost = 'examplesite.ru';
}

That first conditional looks like it could be a solution for your scenario.

[adrian]

Thanks @Robin S for the idea, but I am not sure that it can really help me in this case. It's mostly an issue of my dev/staging vs production both being on the same server. My script which can be run via http and also via cron needs to have the domain hardcoded because there is no way to get the domain via cron. I need to send a webhook endpoint for my site to twilio, so it needs to be either "dev" or no subdomain, but versioning the script between the two environments isn't simple. I have a workaround and I don't expect PW to have a solution for this - it's just that I think the current behavior is confusing.