Anything wrong with using 599, 598 error codes for logic?

I’m new here, thanks. I’m writing rules for Drupal using the Boost
static caching module (like wp-super-cache). Is there anything wrong
with using fake error codes like 599, 598 and internal locations to
control logic?

server {
listen 80;
server_name example.com;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
root /var/example.com;
index index.php;

if ($host !~* ^(example.com)$ ) { # deny illegal host headers
return 444;
}

location / {
rewrite ^/(.*)/$ /$1 permanent; # remove trailing slashes for SEO
error_page 404 @drupal;

try_files $uri @cache;

}

location @cache {
if ( $request_method !~ GET ) {
return 599;
}
if ($http_cookie ~ “DRUPAL_UID”) {
return 599;
}
error_page 599 = @drupal;

expires epoch;
add_header Cache-Control "must-revalidate, post-check=0, 

pre-check=0";
charset utf-8;

try_files /cache/$host${uri}_$args.html @drupal;

}

location @drupal {
rewrite ^/(.*)$ /index.php?q=$1 last;
}

location ~ .php$ {
try_files $uri @drupal; #check for existence of php file
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}

location ~ .css$ {
if ( $request_method !~ GET ) {
return 598;
}
if ($http_cookie ~ “DRUPAL_UID”) {
return 598;
}
error_page 598 = @x598;

access_log      off;
error_log /dev/null crit; # prevent debugging  if compiled 

–with-debug
expires max; #if using aggregator

try_files /cache/$host${uri}_.css $uri @x404;

}

location ~ .js$ {
if ( $request_method !~ GET ) {
return 598;
}
if ($http_cookie ~ “DRUPAL_UID”) {
return 598;
}
error_page 598 = @x598;

access_log  off;
expires  max; # if using aggregator

try_files /cache/$host${uri}_.js $uri @x404;

}

location @x598 {
access_log off;
expires max; # max if using aggregator, otherwise sane expire time
}

location ~* ^.+.(jpg|jpeg|gif|png|ico)$ {
if ($http_referer !~ ^(http://example.com) ) { # prevent image
hijacking
return 444;
}

access_log      off;
expires         45d;

try_files $uri @x404;

}

location @x404 {
return 404;
}

location ~ /. {
deny all;
}

location ~*
((cron.php|settings.php)|.(htaccess|engine|inc|info|install|module|profile|pl|po|sh|.sql|theme|tpl(.php)?|xtmpl)$|^(Entries.|Repository|Root|Tag|Template))$
{
deny all;
}
}

Posted at Nginx Forum:

Hello!

On Sat, Jun 27, 2009 at 01:36:33PM -0400, brianmercer wrote:

I’m new here, thanks. I’m writing rules for Drupal using the Boost static caching module (like wp-super-cache). Is there anything wrong with using fake error codes like 599, 598 and internal locations to control logic?

It should work with recent nginx versions (0.7.51+) but may
produce strange results as long as this errors escape to user due
to config errors. And actually I see no reason to do so in your
config, 405 (Method Not Allowed) looks appropriate in your config.

}
It’s much better to setup separate default server for this. E.g.

server {
listen 80 default;
server_name_in_redirect off;

return 444;

}

location / {
rewrite ^/(.*)/$ /$1 permanent; # remove trailing slashes for SEO
error_page 404 @drupal;

try_files $uri @cache;

Directive error_page seems unneeded here. Additionally it looks
wrong (note that there is no ‘=’).

  return 598;
try_files /cache/$host${uri}_.css $uri @x404;

location ~* ^.+.(jpg|jpeg|gif|png|ico)$ {
if ($http_referer !~ ^(http://example.com) ) { # prevent image hijacking
return 444;
}

access_log      off;
expires         45d;

try_files $uri @x404;

It should be enough to use

try_files  $uri  =404;

instead as of 0.7.51+.

Maxim D.