404 functionality broken for child URLs of panel pages

Additional information: I've disabled Customerror and set the error pages back to defaults. Aside from loss of custom error message on normal 404s, behavior is unchanged.

Additional info:

Drupal does not return 404 on these pages -- to a user-agent, looks just like a normal page.

FWIW, the path for all of these panel pages was set using the "Path" field on the Settings page of the panel.

Additional info: Also fails on 5.x-2.0-RC1a.

[edited to remove example links, which no longer fail]

Escalating to critical, since this site is scheduled to go live in five days and this is just not a viable behavior. Also changing issue title to more accurately reflect the problem, and affected version to reflect that I've updated Panels as part of my debugging process.

No one has responded to this issue. Is this just something no one else has seen? Something no one has any ideas about? I've observed it on my dev system (which is Drupal 5.9 / Panels 2.0-rc1a / Apache 2 / PHP 4.4.7 on OSX) and the production server (Drupal 5.9 / Panels 2.0-rc1a / Apache 2.0.46 / PHP 4.4.1 on Red Hat Linux).

Does anybody have any workarond suggestions? Is there maybe some kind of .htaccess hack I can do to intercept these page load failures? What's the cause of this?

Here's still more additional information:

Paths of the form "[pathname]/" also produce the same results.

For a Path setting of "services", this produces a normal page load:

http://example.com/services
[example removed]

... while either of these would provide a broken version of the same page:

http://example.com/services/
http://example.com/services/melvin

[examples removed]

In the first case, I would expect the behavior to be that the page loads normally. This is what usually happens with pages when you assign them a new URL and then try to load the page with a trailing slash.

In the second case, I'm expecting a normal 404 page.

Not sure what you mean. Problem still exists.

Did you follow the links I gave and not see it? I see it from my work-Mac, from the Parallels instances on that computer, from all the computers in our office, and from my personal Powerbook. So if you're not seeing it, could you share what you did see and what your configuration is?

[edited to replace live example links, which no longer fail]

If you follow a link to a page that's not there, normally you get a "404 page not found" error, returned in teh form of the page you see here:

[1] http://example.com/staging/about-turner-engineering/melvin

However, when the non-existent page is the child of a Panel page, you get a page that has the same content as the panels page, but is broken, as you see here:

[2] http://example.com/staging/services/melvin

Here's the parent page for comparison:

[3] http://example.com/staging/services

So when there's an actual 404 condition, the page looks like [2], which is a mangled version of [3], when it should look like [1].

Page [1] returns an HTTP response code of 404 Page Not Found, which is correct. Page [2] returns an HTTP response code of 200 OK, which is NOT correct. It's dead wrong. I need for [2] to return 404 Page Not Found.

Is that any clearer?

Really, what's going on here is that basic HTTP-related functionality is broken. I need to find a way for it not to be broken. I'd like some suggestions for how to fix or work around this problem. I'm sorry if the use-case has not been clear, but I do not know how to state it more clearly than I have.

[2] should look like [1]. That it doesn't means that Drupal's 404 functionality has been broken.

Additional information: If the URL of the panel page has a file extension, the problem goes away.

That's an unspeakable hack of a workaround, so I'd rather not use it. Does anyone know a possible reason why this is happening, or can anyone suggest any workarounds that don't require faking a file extension on the page?

I've modified the configuration so the test URLs are no longer valid. Did that late last night and was tired enough that I forgot to remove them from the message. The problem still exists, but since I've settled on a workaround, I'll de-escalate this. So the problem still exists, you just can't see it because I've hacked around it.

I'd still like to know what causes this behavior, though.

Here's the workaround:

1. Assign a URL to the Panel that has a file extension (e.g., 'careers.htm'). If you do this, you don't get the broken 404 behavior.
2. Set up a URL Alias of 'careers' for 'careers.htm', so people never have to see the file extension. Now I have the desired page URL ('careers'), without the broken 404 behavior for child pages of that page. (I have no idea why this should work.)

At this point, I'd still get a 404 (but it would be a real 404) at 'careers/', so I installed GlobalRedirect to handle that.

(The "brokenness" of the page that was coming up was due to breaking stylesheet references. I'd hacked the style to insert a version of the URL as a CSS ID for the Body tag, and if there's a trailing slash, #careers becomes #careers_.)

Oh, but that's such a bad mode of function!

There are two huge and deepely problematic assumptions in that "expected behavior":

That people will think in terms of "passing parameters", instead of thinking in terms of the metaphor of directory paths, which is what they've been invested in since they started using computers and which is reinforced everywhere they go on the web.

That people designing information architectures and the system architectures that support them will design them in such a way that it makes sense to think in terms of passing parameters versus browsing to a deeper directory path.

Both of these are intensely user-hostile assumptions.

sdboyer, I've been training computer users for 19 years. I'm not talking out of my ass, and I'm not stopping at some facile interpretation of "directory structures."

People interpret the chain of terms as a deeper-dig into the subject they're looking at the URL, or when they're browsing. That's the point of clean URLs, just like it's the point of breadcrumbs. This breaks that mental model.

Get past your rationalizations and accept that finding something where you should find nothing is a big usability problem.

BTW, I do now realize I have encountered this before. In my work I get to do web development maybe one month out of twelve, in man-hours, so I don't always remember all the old issues I've dealt with. That it's old behavior doesn't make it right. It actually makes it more egregious. And in my responses to you, I'm not saying it's a Panels issue. You've established that it's not, and I'm not contradicting you. I'm just saying that it's bad and, to someone with real-world interaction design experience, it should be obviously bad.

And the dismissive, user-hostile arrogance of many core contributors is one of the few really troubling things about Drupal. It ticked along for years with major SEO issues, for example, because of stuff like this; people have had to add modules to fix basic problems like apparent duplication of content (caused by being able to access identical pages with different URLs, which has always been a major SEO no-no).