[wp-trac] [WordPress Trac] #14971: X-Pingback header set when no pingbacks accepted

[WordPress Trac]

#14971: X-Pingback header set when no pingbacks accepted
------------------------------+---------------------------------------------
 Reporter:  niallkennedy      |       Owner:                 
     Type:  enhancement       |      Status:  new            
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  Pings/Trackbacks  |     Version:                 
 Severity:  normal            |    Keywords:  has-patch      
------------------------------+---------------------------------------------

Comment(by filosofo):

 Replying to [comment:3 niallkennedy]:
 > Should a include a stylesheet it knows will 404? A pingback advertised
 on a non pingback-enabled resource is setting up an additional client-
 server roundtrip we know will fail.

 There are two separate issues involved here: the location of the pingback
 / XML-RPC server and the permissions afforded to the client regarding that
 server.

 When pingbacks are disabled, the pingback / XML-RPC server ''still
 exists''; the location has not changed. It's just not accepting pingbacks
 for the target URI.

 Think about it from the client's perspective: it's much more informative
 for it to be able to say "Bob's site is not accepting pingbacks for the
 target URI" than "Bob's site does not appear to support pingbacks at all."

 And, as mentioned in most cases this will result in more bandwidth-
 intensive requests: if the `X-Pingback` HTTP header is missing, the
 client's supposed to retrieve the target URL and parse the page for the
 pingback link element.  It's much more efficient for it instead to get the
 denied response from the pingback server.

 > We are trying to deliver the "resource does not support pingback"
 response.

 No.  The resource supports pingbacks; it's just denying them.  It's the
 difference between on one hand hanging a sign in your shop door that says
 "Closed" after hours and on the other hand pretending that the shop
 doesn't exist.


 > Seems best to remove the resource's external link you know will fail.

 The link shouldn't fail when the server is there, any more than we would
 say `wp-admin` "fails" when it redirects an unauthenticated user to `wp-
 login.php`.  It's just the ''specific request'' that is denied.  That's
 not the same as a resource failure.

 > The spec discourages use of both the HTTP header and link rel=pingback.

 True, but the reality is that most WordPress themes do this.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14971#comment:4>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software