X-Pingback header set when no pingbacks accepted

[niallkennedy]

The send_headers function in wp-includes/classes.php sets the X-Pingback header when initializing the headers array. It's possible the site has disabled link notifications from other blogs (pingbacks and trackbacks) through the default_ping_status option exposed in Discussion Settings.

WordPress should only advertise the header when a given site has enabled pingbacks. Requires moving X-Pingback out of the initial headers variable and into a conditional.

The default_ping_status option sets a default that may be overridden in each post. The attached patch only addresses the site-wide option but does not take into consideration a request for a post or page which may enable a pingback regardless of the site-wide default.

[niallkennedy]

only set X-Pingback header if default_ping_status is open

[filosofo]

Replying to niallkennedy:

WordPress should only advertise the header when a given site has enabled pingbacks. Requires moving X-Pingback out of the initial headers variable and into a conditional.

I'm not sure about this. Wouldn't it be better to respond according to the ​spec with an error code 49, "Access Denied"? (I have no idea what it currently does.)

It's not that the XMLRPC server resource doesn't exist; it's that pingbacks aren't allowed. Having an accurate error response would be more helpful for the pinging client, because then it knows that there is a policy preventing pingbacks and not just that it has the wrong location or there is a temporary resource failure.

Also, the X-Pingback header is only one way of providing server auto-discovery; the other is the <link> HTML head element, which is baked into many WP themes.

[demetris]

Replying to filosofo:

Also, the X-Pingback header is only one way of providing server auto-discovery; the other is the <link> HTML head element, which is baked into many WP themes.

... including the default Twenty Ten.

I asked on the dev channel the other day if we really need that in Twenty Ten’s HTML head. I mean, are there clients the rely on it and only it? And, if yes, are they of a kind that we should care about?

[niallkennedy]

Replying to filosofo:

I'm not sure about this. Wouldn't it be better to respond according to the ​spec with an error code 49, "Access Denied"? (I have no idea what it currently does.)

It's not that the XMLRPC server resource doesn't exist; it's that pingbacks aren't allowed. Having an accurate error response would be more helpful for the pinging client, because then it knows that there is a policy preventing pingbacks and not just that it has the wrong location or there is a temporary resource failure.

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.

A pingback-enabled resource MUST either be served with an X-Pingback HTTP header or contain a <link> element, or both.

I believe a blog with default ping status set to off, and all posts set to off is not pingback-enabled. Similarly, a post with ping status set to off is not pingback-enabled.

The discovery process described in the spec:

1. Look for X-Pingback header
2. If none, look for link rel=pingback URI
3. If none, this resource does not support pingback

We are trying to deliver the "resource does not support pingback" response. Not advertising the pingback endpoint in HTTP headers or in <link> meets that requirement. An XML-RPC response from the pingback server also satisfies, and should be in place just in case the endpoint is queried for the target URI. Seems best to remove the resource's external link you know will fail.

Also, the X-Pingback header is only one way of providing server auto-discovery; the other is the <link> HTML head element, which is baked into many WP themes.

HTML and XHTML documents MAY include a <link> element in addition to an HTTP header, although this is discouraged.

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

[filosofo]

Replying to 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.

[nacin]

Replying to filosofo:

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

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

Including Twenty Ten, Kubrick, and Classic.

[markjaquith]

• I agree with filosofo's comments
• This can break Pingback support on posts that have Pingbacks enabled (global: closed, post: open)
• This header is useful for determining the WordPress install directory

[SergeyBiryukov]

Follow-up: #20226