See also #21579 where a similar issue occurs with paged comments. Invalid comment pages, for example ​http://example.com/content/comment-page-999/ do not return a 404 but equally do not find any comments! Is a new ticket needed or can we use this one to fix the 404 issue in both cases and #21579 to generate the proper rel="canonical" in both cases?

1) site/post/## - where ## is non-existant - should 404 or 301 not 200 duplicate content
2) site/post/## - where ## > 1 - rel=canonical should be site/post/## not duplicate first page site/post based on :

The patch I just added fixes point 1 in @here's comment above: ie. the fact that WP serves a 200 for a page that doesn't exist by, if the post is paginated, checking how much pages are in the post and acting accordingly, by either redirecting to the first page of the post or by providing a proper URL.

Looking at how it's dealt with in post-template.php a bit more, this probably should actually be done a bit different. I think _wp_link_page should be split up and part of that should be in link-template.php, which should then be used by _wp_link_page and the functions above...

The last ticket introduces get_paginated_post_url, for which the functionality is removed from _wp_link_page and now used in both _wp_link_page in post-template.php and rel_canonical in link-template.php. This looks a lot cleaner to me than what we had so far and also allows for future use of get_paginated_post_url within a patch for #18660.

Canonical/Rewrite: sanity check posts that are paged with <!--nextpage-->. Page numbers past the max number of pages are returning the last page of content and causing infinite duplicate content.

Awesome rewrite bug: the page query var was being set to '/4' in $wp. When cast to int, it returns 0 (Bless you, PHP). WP_Query calls trim( $page, '/' ) when setting its own query var. The few places that were checking page before posts were queried now have sanity checks, so that these changes work without flushing rewrites.