[wp-trac] [WordPress Trac] #17246: Handling of HTTP 404 errors for non-existing files

WordPress Trac noreply at wordpress.org
Thu Aug 16 19:37:59 UTC 2018


#17246: Handling of HTTP 404 errors for non-existing files
----------------------------+--------------------------
 Reporter:  azaozz          |       Owner:  (none)
     Type:  enhancement     |      Status:  reopened
 Priority:  normal          |   Milestone:
Component:  Bootstrap/Load  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:  performance
----------------------------+--------------------------
Changes (by rpayne7264):

 * status:  closed => reopened
 * resolution:  maybelater =>


Comment:

 Aborting execution with a die() is not the answer, young Padawan, as that
 will kill the entire request.
 I only want to abort execution of my plugin code if I know the request is
 for a script, image, or stylesheet, because my plugin doesn't provide any
 useful functionality for those types of files.

 I have submitted proposed code for adding a highly-extensible
 wp_is_bad_request() function to the core, thus making such checks an easy
 matter for all plugin and theme creators. See #41934



 Replying to [comment:7 dd32]:
 > I'm re-closing this as `maybelater` as I don't think anything has
 changed here that gives any reason to look at it again.
 >
 > > I propose that we add a wp_abort_execution filter to the core, which
 would allow developers to tell Wordpress whether or not to load their
 plugin.
 >
 > If you wish to abort a request, you can simply call `die()` upon plugin
 inclusion if certain criteria are met, or you could delay it until
 WordPress is fully loaded (`init`) to allow other plugins to handle the
 request if they wish (Such as a stats plugin which wants to record all
 404's).
 >
 > > Personally, I am now including a check in all of my plugins, after
 realizing the Wordpress process executes for all missing files referenced
 in client-side mark-up.
 >
 > I'd be very careful about doing that - It's expected that
 `/blah/blah/filename.jpg` be a request that's routed to WordPress and
 handled sometimes by plugins.
 >
 > Personally I see the bug being that either the server is routing file-
 requests to WordPress when you don't want it to, or that markup is being
 used which references invalid paths.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/17246#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list