[wp-meta] [Making WordPress.org] #5184: Homepage requests with a 'page' parameter should return a 404

[Making WordPress.org]

#5184: Homepage requests with a 'page' parameter should return a 404
----------------------------+--------------------------------
 Reporter:  jonoaldersonwp  |       Owner:  (none)
     Type:  defect (bug)    |      Status:  closed
 Priority:  lowest          |   Milestone:
Component:  General         |  Resolution:  reported-upstream
 Keywords:  seo             |
----------------------------+--------------------------------

Comment (by johnjamesjacoby):

 I've done some independent research related to this, so I figured I'd
 share what found:

 HTTP Codes:
 * `301` is not quite right because it communicates ''permanent'' non-
 existence
 * `404` is currently best because it communicates ''current'' non-
 existence
 * `416` means "Range Not Satisfiable" but has a specific use-case that
 does not apply here (at all)
 * There isn't a better response code than `404` to communicate that a
 request is ''out-of-bounds'' or what the boundaries would be relative to a
 specific URI

 WordPress Code:
 * The way that `redirect_canonical()` integrates with pagination is
 specific to something like `/page/1/` or `page=1`, and is consistently
 handled for all core cases (archives, multi-page singulars, comments,
 etc...), and also properly do a 301 back to the root/canonical URI – it
 does not redirect page requests that are too large
 * I noticed that `wp_get_canonical_url()` ''does'' handle pagination query
 variables, but ''does not'' currently consider `is_front_page()` and the
 difference between `page` and `paged`, though I have not confirmed if that
 matters yet
 * The `cpage` query var for Comments may be worth checking too, if
 paginated comments are set anywhere and out-of-bounds requests are being
 made/crawled

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/5184#comment:18>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org