Multiple Wan IP Addresses, Single LAN IP Address

We are using NGINX .7.6 as a reverse proxy to an IIS webserver. We are
trying to serve our images from a separate domain and IP that proxies to
the same IIS root as the primary website. Both IP addresses are on the
same subnet. The primary domain is on 67.111.111.1 and the image domain
is on 67.111.111.12.

The NGINX config related to these two sites is as follows -

upstream primary_com {
server 10.1.1.2 weight=10 max_fails=3 fail_timeout=30s;
server 10.1.1.1 weight=1 backup;

}

upstream primary_com_ssl {
server    10.1.1.2:443 weight=10 max_fails=3 fail_timeout=30s;
server    10.1.1.1:443 weight=1 backup;

}


server {
     listen    80;
     server_name  67.111.111.1
  primary.com
                    www.primary.com;




     access_log  /var/log/nginx/primary.access.log;



    location / {
proxy_pass  http://primary_com;


    }



}



server {
     listen      443;
     server_name    67.111.111.1
    primary.com
    www.primary.com;

     access_log    /var/log/nginx/primary.ssl.access.log;

error_log /var/log/nginx/primary.ssl.error.log;

     ssl      on;
     ssl_certificate   /etc/ssl/primary/disccert.pem;
     ssl_certificate_key  /etc/ssl/primary/disckey.pem;

ssl_ciphers ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP;
ssl_protocols SSLv3 TLSv1;

     location / {
          proxy_pass  https://primary_com_ssl;
     }


}

upstream images_com {
server 10.1.1.2 weight=10 max_fails=3 fail_timeout=30s;
server 10.1.1.1 weight=1 backup;
}

server {
listen 80;
server_name 67.111.111.12
www.images.com
1.images.com
2.images.com
3.images.com;

   access_log      /var/log/nginx/images.access.log;


   ## Only requests to our Host are allowed
   if ($host !~ 

^(images.com|www.images.com|1.images.com|2.images.com|3.images.com|4.images.com)$
) {
return 444;
}

location ~* (\.jpg|\.png|\.gif|\.css)$ {

           valid_referers
                   none
                   blocked
                   images.com
                   www.images.com
                   images.com
                   www.images.com
                   1.images.com
                   2.images.com
                   3.images.com
                   4.images.com;

           if ($invalid_referer) {
                   return 444;
           }



proxy_cache_valid 200 301 302 1480m;
expires  10d;
proxy_cache dci;
proxy_cache_use_stale  error timeout invalid_header updating;
proxy_pass     http://images_com;
}

When images are pulled through the images domain the rendering of the
images slows considerably. I am sure it is not related to the line
speed, latency, or dns servers. It appears there is something happening
on the proxy side either in pulling the images from the backend server
or in its attempt to respond to the outside request. Is there anything
that needs to be done in the upstream or listen section to make this
process efficient?

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,97002,97002#msg-97002

Hi Folks,

We are running into a small problem with bad HTTP clients.

We have sold a bunch of hardware with embedded HTTP clients which don’t
URL-encode the parameter values. For example:

GET /a/r?did=X234 567 Y HTTP/1.1

We were using a pair of Apache servers behind a hardware load-balancer
and
switched our environment to front those Apache servers with a pair of
Nginx
servers. We actually use those Nginx servers for a number of other web
sites
we serve.

When we made this switch, these particular clients stopped working.
Nginx is
responding immediately after receiving the “GET” line above with “400
Bad
Request”. This is valid behavior on Nginx’s part, as according to our
understanding of the HTTP protocol, no spaces are allowed in the request
URI.

Apache is apparently rather forgiving on this front. Is there some
setting
or configuration parameter in Nginx that would make it more forgiving of
these spaces in the request URI?

If there is not, would it be difficult for us to modify Nginx to make it
more forgiving? If so, any pointers as to where to start?

Our other options we can think of are:

  1. route HTTP traffic from these clients to Apache servers
  2. leave them dead in the water until customers complain so we can tell
    them
    to upgrade their firmware for the fix

Thanks for any help or pointers you can offer.

-peter