[wp-trac] [WordPress Trac] #14348: If it's a HEAD request, stop after the head!
WordPress Trac
wp-trac at lists.automattic.com
Mon Sep 26 06:34:48 UTC 2011
#14348: If it's a HEAD request, stop after the head!
---------------------------------------------+------------------
Reporter: mitchoyoshitaka | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: 3.3
Component: Performance | Version: 3.0
Severity: normal | Resolution:
Keywords: has-patch 3.3-early 2nd-opinion |
---------------------------------------------+------------------
Changes (by mbijon):
* keywords: has-patch 3.3-early => has-patch 3.3-early 2nd-opinion
Comment:
It's not only feeds, but do_robots() (called for robots.txt) that get a
lot of HEAD requests. On this count either attachment:14348.diff or
template_redirect seem better than template_include.
I tested using Fiddler to send HEAD requests & compare the two that "seem
better".
Any change on this ticket will require some plugin updates, but
template_redirect seems like the option with better workaround vs
attachment:14348.diff
----
== Feed Tests ==
attachment:14348.diff doesn't respond with the expected 302 redirect in
most feed plugins, instead it sends a 200. Then the time in the 200
response to HEAD doesn't match the ones in a follow-up 302 > 200 sequence
sent to a GET.
* BTW, I checked 5 higher-rated ones & they mainly seem to hook
send_headers or template_redirect
* If we use template_redirect then send_headers could be hooked to fix
any broken plugins. With the other option, any feed plugins would need to
negate this whole tweak with $exit_on_http_head
* Also tested the old Feedburner FeedSmith. It breaks because it hooks
template_redirect
* This plugin is still out there semi-frequently & isn't likely to get
updated either
== Robots Tests ==
I also tested several robots.txt plugins and they all work as expected
with either attachment:14348.diff or template_redirect.
* The only odd thing was one plugin that logs the requester/bot from
do_robot. Currently it logs both on HEAD & GET requests.
* Either of the performant fixes limits logging to only GETs (but that's
what I personally would have expected).
(FYI that I did this testing on a 3.2.1 setup. Robots.txt requests failed
with a 404 to either GET/HEAD, from [18776], but I wasn't sure if that was
due to the plugins not being 3.3 compatible yet. '''Could someone else
confirm if this might be a bug in do_robots()?''')
== Caching tests ==
Caching plugins do play here too, but the two biggest aren't impacted.
They both handle HEAD requests in their own ways:
* One responds directly to HEAD based on cached files or an internal GET &
won't break on either change
* The other has an odd execution path (& I was too lazy to follow it) but
in testing it responded to repeat GET/HEAD requests fine whether the
initially cached request was a HEAD or GET
--
Ticket URL: <http://core.trac.wordpress.org/ticket/14348#comment:21>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list