[wp-hackers] cheap 404 serving

[Ryan McCue]

"Matthias P. Würfl" wrote:
> I meant conditions that show that this file should be served by
> Wordpress. These URIs ending "/" or ".html" should be served by
> Wordpress. Others (".jpg") should not be served by Wordpress even if the
> file doesn't exist.

Ah, I appear to have read that backwards, apologies!

".jpg" could theoretically be handled by WP (I think some attachment
pages might have URLs which look like /2012/10/16/abc.jpg/ from memory),
so unless you know for sure, you can't rely on this.

> Headers don't *do*, they just *tell* what the client expects. If the
> Accept-header is "image/jpeg" i know theres no sense in sending this
> request to WP (correct me if I'm wrong).

Not always; sometimes, WordPress might want to be the one to serve up
things like this. Especially in plugins where there might be dynamic
image generation or similar. Ditto for Javascript and CSS.

> 
>>> Are there any ready-to-use recipes to serve 404 errors cheaper? For
>>> Nginx? :-)
>> Alright, so as far as I can tell, this breaks down into a few places:
>>
>> Anything starting with "wp-admin/", "wp-content/" or "wp-includes/" can
>> be ignored, since WP rewrite rules should never touch those.
>>
>> Something like this should fix that (for nginx):
>>
>>     location ~* ^(/wp-includes|/wp-content|/wp-admin) {
>>         try_files $uri $uri/ =404;
>>     }
>>
>> (Assuming you're not using the 404 handler for WordPress; please don't
>> do that.)
> 
> I don't understand that. How can that catch all the requests to
> /favicon.ico, /robots.txt, /phpmyadmin and /othernonexistant.file?
> Where's php in here at all?

So, WordPress could theoretically have a page called "/phpmyadmin/", so
you don't want to stop that from going to WP. The idea of using WP as
the default handler is that nginx doesn't know whether WP can serve a
page ahead of time, so it passes all unknown URLs in.

What that rule says is: I know that nothing which starts with
wp-includes, wp-content or wp-admin is going to be used in WordPress'
rewrite rules internally, so don't bother.

> My current configuration is:
> 
>     location /acv/ {
> 
>         try_files $uri /acv/index.php?q=$uri;

You might want to change this to check $uri/ as well if you're ever
doing directory listing.

>         location = /acv/wp/wp-admin/ {
>            rewrite $uri index.php;
>         }

Shouldn't that be handled by your `index index.php` line? If not, adding
$uri/ to your try_files should handle it.

> Then the missing "foo.gif" takes 1ms instead of 400ms. Imagine a gallery
> site where all images disappear for some reasons: the server will crash
> with the first configuration while it will stay online (and wait for
> some rsync to add the missing pictures again) and happyly serve all the
> 404.
> 
> So my question is: How can i send as much 404s without wordpress without
> having "false negatives".

As I mentioned before, you can't really know if WordPress (or a plugin)
is going to try and handle a URL before you actually ask it to. If
you're 100% in control of your server (including content, plugins, etc)
and you can guarantee that it's not going to ever have any need to touch
URLs like that, then you can just do:

	location ~* \.(gif|jpeg|jpg|png)$ {
		try_files $uri =404;
	}

That'll tell nginx to only try serving that file and then give up.

----

Another option is to make sure all your URLs are prefixed with something
(e.g. posts begin with /blog/, pages begin with /other/), then you can
just make WordPress serve up if the URL starts with those. Be /very/
careful using this though.

-- 
Ryan McCue
<http://ryanmccue.info/>