在不执行完整的HTTP GET的情况下检测WordPress URL？

我正在尝试编写一个单选框例程，该例程为WordPress博客条目提供特殊待遇。因此，给定一个简单的，未经修饰的URL，例如

http://blog.stackoverflow.com/2011/03/a-new-name-for-stack-overflow-with-surprise-ending/

我如何才能检测到这是WordPress安装，理想情况下无需对看到的每个URL进行完整的HTTP GET？

当然，我们可以从WordPress URL的通用约定开始，这至少消除了某些URL的争用。在这种情况下是...

http://example.com/year/month/slug-goes-here

但这也不是一个通用常数。

我尝试使用HTTP HEAD查看该URL的标题，然后看到：

Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:18340
Content-Type:text/html; charset=UTF-8
Date:Thu, 07 Jun 2012 07:07:38 GMT
Keep-Alive:timeout=15, max=100
Server:Apache/2.2.9 (Ubuntu) DAV/2 PHP/5.2.6-2ubuntu4.2 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
Vary:Cookie,Accept-Encoding
WP-Super-Cache:Served legacy cache file
X-Pingback:http://blog.stackoverflow.com/xmlrpc.php
X-Powered-By:PHP/5.2.6-2ubuntu4.2

我认为依靠的存在并不是WP-Super-Cache特别可靠，这是我在标头中看到的唯一有用的东西，因此在WordPress安装中可能只有零个通用HTTP标头吗？

根据我的经验和快速的代码搜索，WP 并没有故意在标头中标识其自身。但是，有些似乎足够独特并且不太可能进行定制。

HEAD /wp-login.php将包含用于.org安装的以下内容：

 Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/

对于.com：

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/; domain=.wordpress.com

Cookie名称可以通过定义TEST_COOKIE常量进行自定义，但是WP Cookie check字符串在核心中进行了硬编码，并set_cookie()在文件的源代码中对此进行了调用。

为了定位wp-login.php，有一些URL快捷方式（wp_redirect_admin_locations()自WP 3.4起实现（请参见故障单＃19607）：

/login网站根目录上的内容确实会302重定向到wp-login.php，无论它在哪里。

因此，如果无法将WP安装并限制在子目录中，而根本不用于管理站点的根，则无法可靠地检测到这种情况。

将HEAD请求发送到/wp-feed.php与该目录相同的目录/xmlrpc.php（即使在子目录安装中）。在WordPress中，您将获得Location标头作为包含字符串的响应feed。

在您的示例中，blog.stackoverflow.com您将获得：

HTTP/1.1 301 Moved Permanently\r\n
Date: Thu, 07 Jun 2012 07:30:10 GMT\r\n
Server: Apache/2.2.9 (Ubuntu) DAV/2 PHP/5.2.6-2ubuntu4.2 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g\r\n
X-Powered-By: PHP/5.2.6-2ubuntu4.2\r\n
Location: http://blog.stackoverflow.com/feed/\r\n
Vary: Accept-Encoding\r\n
Content-Type: text/html; charset=UTF-8\r\n
\r\n

xmlrpc.php仅仅存在一个文件还不够安全。任何人都可以将此名称命名为文件。

注意：X-Pingback可以通过过滤禁用标头'wp_headers'。所以我的建议不是防弹的。

相关：采取步骤隐藏网站使用WordPress的事实？

附加URL ?page_id=-1并为此执行HTTP HEAD请求。

在自行安装的WordPress博客上，这将导致404响应。

在wordpress.com博客上，这将导致301响应（如果您遵循重定向，则最终将获得200响应）。

在非WordPress网站上，您应该获得200的响应（假设没有查询字符串的原始URL给出200）-查询字符串应该没有任何区别。

HEAD请求示例http://blog.stackoverflow.com/2011/03/a-new-name-for-stack-overflow-with-surprise-ending/?page_id=-1：

HTTP/1.1 404 Not Found
Server: Apache/2.2.9 (Ubuntu) DAV/2 PHP/5.2.6-2ubuntu4.2 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
Content-Encoding: gzip
Vary: Cookie,Accept-Encoding
Cache-Control: no-cache, must-revalidate, max-age=0
Last-Modified: Thu, 07 Jun 2012 08:53:01 GMT
Date: Thu, 07 Jun 2012 08:53:01 GMT
Keep-Alive: timeout=15, max=100
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Pragma: no-cache
Connection: Keep-Alive
X-Powered-By: PHP/5.2.6-2ubuntu4.2
X-Pingback: http://blog.stackoverflow.com/xmlrpc.php
Content-Type: text/html; charset=UTF-8

带有HEAD请求的示例http://dailycrave.wordpress.com/2012/06/01/three-cheese-grilled-pizza/?page_id=-1（以下重定向已关闭）：

HTTP/1.1 301 Moved Permanently
X-Pingback: http://dailycrave.wordpress.com/xmlrpc.php
Server: nginx
Expires: Wed, 11 Jan 1984 05:00:00 GMT
X-Hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.
Location: http://dailycrave.wordpress.com/2012/06/01/three-cheese-grilled-pizza/
Pragma: no-cache
Cache-Control: no-cache, must-revalidate, max-age=60
Connection: close
Last-Modified: Thu, 07 Jun 2012 09:01:09 GMT
Content-Type: text/html; charset=UTF-8
Date: Thu, 07 Jun 2012 09:01:09 GMT

（请注意X-Hacker复活节彩蛋！）

如果您遵循wordpress.com博客的301重定向，则会遇到以下问题：

HTTP/1.1 200 OK
Server: nginx
Vary: Accept-Encoding, Cookie
Last-Modified: Thu, 07 Jun 2012 09:48:26 GMT
Cache-Control: max-age=172, must-revalidate
Connection: close
Date: Thu, 07 Jun 2012 09:50:34 GMT
Transfer-Encoding: Identity
Content-Encoding: gzip
Link: <http://wp.me/pXGqK-27g>; rel=shortlink
X-Pingback: http://dailycrave.wordpress.com/xmlrpc.php
Content-Type: text/html; charset=UTF-8
X-Nananana: Batcache
X-Hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.

请注意，包含http://wp.me/URL 的“链接”标头似乎是所有wordpress.com托管博客所共有的，可用于标识它们。

我相信这是可行的?page_id=-1，因为传入URL会覆盖来自URL段的默认路由。不会有ID为-1的页面，因此将提供404 /重定向。

wp-super-cache在所有wordpress安装中均不可用，URL中也没有任何固定格式。虽然永久链接设置页面确实提供了一些可以使用的URL方案的固定设置，但任何人都可以使用任何自定义URL方案。例如，如果任何人只是决定仅使用URL中的页面/帖子名称，则几乎无法确定它是否是Wordpress网站。

可以使用xmlrpc的存在来检测，但是可以再次禁用它。

最后，即使您对URL进行了完全了解，也仍然不可能100％地检测到页面是否使用wordpress构建。这完全取决于主题模板及其开发方式。

一种相当可靠的方法是查找状态wp-login和wp-admin。但是，即使这些也可以移动。我会选择这种方式。

注释有两种选择，设置您自己的WordPress标头。将其放在主题的functions.php中。

add_action('template_redirect', 'add_wp_header');
function add_wp_header(){

header('Type: WordPress');
}

WP扫描指纹识别器（红宝石），它通过几个步骤来尝试确定是否正在使用WordPress，例如查找插件目录，主题名称，元标记，自述文件等（我不知道这实际上有多准确） ）。http://code.google.com/p/wpscan/source/browse/#svn%2Ftrunk%2Flib%2Fwpscan

向以wp-开头的文件之一发送头请求怎么样。理想情况下，请查看wp-login.php。如果存在，则表示该网站正在运行WordPress。