I can not confirm this

What could be the difference?

@joeforjoomla Your website is multilingual, @brianteeman tests most likely on the website with one language.

Obviously i've tested even without multilanguage enabled... same issue

I confirm the issue here.

Conditions
Legacy monolanguage site updated since 1.6. to staging.
New router set for com_content.
default data.

link to an article
http://localhost:8888/trunkgitnew/single-article.html
(Displays here Australian Parks)

If I enter
http://localhost:8888/trunkgitnew/noexists.html

I am redirected to the Home page. No 404.

I get a 404 IF I use legacy router.

@Hackwar
Can you look at this?

Sorry (i forgot to turn on the modern router)

@Hackwar
I guess this one can't be considered as "expected behaviour".

This is actually undefined behavior in our router that can not be fixed in a backwards compatible way. Since that is the case, I opted to go the safe route instead of breaking half the extensions out there and thus making 90% of all URLs throw a 404.

In an ideal world, the router would take a URL in whatever format we have and then convert that URL from whatever format into a non-SEF format. There is very little that the router can actually do to validate an adress. index.php?option=com_content&view=article&id=42 might be a valid article or it might not. The component would later have to throw a 404 in that case. The router could only notice that the URL might be bogus if after all transformations there is still a path left (=a part that is still SEF). That would require that all component routers and all routing rules from third partys properly remove the parts of the URL that they processed. That unfortunately is not the case. So we have 2 choices here: break B/C and throw 404s or not break B/C and have more false positives.

Well there must be an alternative solution to not break any B/C and instruct at least the com_content that it must throw a 404 page. It must be found in some way, after all it worked till nowadays.

No, it did not. It showed random articles instead of the homepage, but otherwise it did not properly throw a 404

The fact still is that legacy router now works fine for the 404 and not the "modern" router.

That is a false statement.

Certainly not. I suggest you test for yourself.
Backend settings for com_content

Normal article link

Not existing

test /6-bogus
That should throw a 404, right? Legacy routing displays the australian park article, while modern routing displays the homepage.

I understand what's saying @Hackwar, but @infograf768 is right. The behaviour of Joomla since ages worked as expected throwing 404 when needed, so blaming a new brand routing system that fails is not really good. We have a problem here. @Hackwar please take some more time to analyze a possible solution and improve the modern router

No rush after all

I explained the solution and the consequences here: #12822 (comment)
And I also explained why this is a break in B/C. Unfortunately this is a mute discussion as long as you guys simply demand that something works one way and don't accept the implications that come with that. Feel free to look at the code and propose how this could be solved. Just keep in mind that it still needs to fulfill the requirements that I described above.

In the content router.php
`public function getArticleId($segment, $query)
{
if ($this->noIDs)
{
$db = JFactory::getDbo();
$dbquery = $db->getQuery(true);
$dbquery->select($dbquery->qn('id'))
->from($dbquery->qn('#__content'))
->where('alias = ' . $dbquery->q($segment))
->where('catid = ' . $dbquery->q($query['id']));
$db->setQuery($dbquery);

        return (int) $db->loadResult();
    }

    return (int) $segment;
}`

when an article ID is not existing you return 0, so in the standard.php would not be possible stop the routing or throw a 404 here:

`else
{
if (is_callable(array($this->router, 'get' . ucfirst($view->name) . 'Id')))
{
// Hand the data over to the router specific method and see if there is a content item that fits
$key = call_user_func_array(array($this->router, 'get' . ucfirst($view->name) . 'Id'), array($segment, $vars));

                    if ($key)
                    {
                        // Found the right view and the right item
                        $parent = $views[$vars['view']];
                        $vars['view'] = $view->name;
                        $found = true;

                        if ($view->parent_key && isset($vars[$parent->key]))
                        {
                            $parent_key = $vars[$parent->key];
                            unset($vars[$parent->key]);
                            $vars[$view->parent_key] = $parent_key;
                        }

                        $vars[$view->key] = $key;

                        break;
                    }
                }
            }`

The solution would be what I did in #12875

No, throwing a 404 simply because the last segment was not discovered as an article will not work. Because you can take a plugin and rewrite the pagination for the blog view to use /page-2, etc. instead of ?start=2, which means that that segment might be an article or it might be the page to start from.

I understand @hackwar, that's not easy. Obviously it's better having some more false positives that break B/C and all extensions out there. If anyone has some ideas... greatly accepted

As I said, the changes in #12875 are doing exactly what you want. Unfortunately not B/C and thus only for 4.0. You guys could concentrate on that and we could get that one out the door soon.

Please test #14542