does that happens in CLI scripts?

@andrepereiradasilva I'm not sure, but I would venture to say that it's not CLI scripts.

The server logs just say mod_fcgid: stderr: mod_fcgid: stderr: PHP Notice: Undefined index: HTTP_HOST /libraries/joomla/application/web.php on line 863

i said that because in CLI scripts normally the HTTP_HOST doesn't exist.

Bur the method is detectRequestUri and i don't believe some CLI script is calling that.

is this the same as #7757 ?

@andrepereiradasilva I don't believe that /libraries/joomla/application/web.php is ever used via CLI.

As far as I know all the use on the site for testing is related to web access not cli. I don't believe this is the same, or even related to the issue you mentioned (as it's throwing the error from a completly different file).

JApplicationWeb CAN be booted from a CLI environment. So in some ways it's relevant.

Thank @mbabker I was unaware that "JApplicationWeb CAN be booted from a CLI environment."

So CLI is relevant, but unknown if CLI is part or source of the issue.

check your cron

I have no server level cron tasks, and the one extension that I know has a cron like task that runs in CLI doesn't seem to call JApplicationWeb or JUri

I will note that I recently read "$_SERVER['HTTP_HOST'] is not available when php is executed on the command line "

Which sounds like all cases where code is accessible via CLI will need to address the possibility that Undefined index: HTTP_HOST will happen under CLI

I did take a GEOIP check against the IP that triggered the notice and I am sure it's just someone who happened onto the site via the web. So the issue is caused by either a script the triggers running something in CLI, or it's some other issue.

I mean JApplicationWeb should only be called from web interface (hence its name). Without some way of reproducing how to handle HTTP_HOST not being defined I'm not sure there's a lot we can do. I'm going to close the issue for now. But if we find a reproducible valid use case we can easily reopen it :)

With 5f03cec it shouldn't be an issue anymore.

If JApplicationWeb can ONLY be called from a web compatible SAPI then like it's CLI counterpart there should be measures to block instantiation in a non-compatible environment. Fact is aside from the lack of $_SERVER data to deal with its URI features the web app is fully usable in a CLI environment and we (ab)use it in Framework apps (all of our apps that have Twig extensions have a dependency to an application class, usually web, and to compile Twig's cache from a command-line context Twig needs this dependency to boot the extensions).

@mbabker Since the error was on line 863 related to Apache I don't believe 5f03cec will fix this issue. Line 860 at the first if would need to be corrected with isset($_SERVER['HTTP_HOST'])

As I stated in opening this "I'm sure something much more complex than isset($_SERVER['HTTP_HOST']) is needed to properly correct this"

This is not related to Apache. The error is related to Joomla. We have NginX with the same error message. They do have a fix in the Joomla area.

Do you have a set of instructions for how to trigger this error?

Yes, when we're logged into the admin area we hit the site name at the top right to direct to the main page to check our changes, when the page loads, it's leaving off the /en/ which is a redirect error for languages.

So instead of loading

https://www.website.com/en/

it instead loads

http://www.website.com

If you hit reload, it loads fine.

Re-opened now we have some reproducable method to test

This can be closed per PR #17655.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/10203

closed in Favor of Pull Request #17655.

Thanks for Hint @Quy.