Everything after the ? is considered part of the query string. Everything before the ? is part of the pretty permalinks, aka rewrite rules.
Rewrite rules are then processed to generate query variables. These are then plugged into a query ( which powers the main loop ), and a template is loaded based on this query.
The parameters that come after the ? in the URL can be used to add new query vars, or just plain GET variables.
So sitename.com/123/wrong-words?some=params&etc=etc is actually just sitename.com/123/wrong-words as far as the rewrite rule system is concerned. Rewrite rules are also powered by regular expressions, and the regular expression used to match a blog post, depends on how your pretty permalinks are configured.
Because of this, the same data is extracted from sitename.com/123/correct-full-postname and sitename.com/123/correct-full-postname/somemistakeword/, and since the only difference is a slash, they’re considered equivalent. Some processing of the URL may also take place, and there is a canonical URL redirection routine which is quite complicated, and large in scope in WP Core.
As for why sitename.com/123/correct-full-postname/somemistakeword doesn’t redirect to sitename.com/123/correct-full-postname, this is because they aren’t the same, there is no post at sitename.com/123/correct-full-postname/somemistakeword. There are rewrite rules that would pick up sitename.com/123/correct-full-postname/2 aka page 2 of that post, and other specific endpoints such as sitename.com/123/correct-full-postname/feed etc
But if we implemented such a feature, it would not be so simple, for example, what would happen if we visit this page:
sitename.com/parentpage/childpage
Would it:
- Show you child page
- Redirect you to parentpage
- 404
As a sidenote, I have a blog post at:
http://tomjn.com/2015/05/07/escaping-the-unsecure/
If I remove the trailing slash, it redirects to the version with the trailing slash. If I append random characters to the end, I get a 404 as expected