Custom Query (2297 matches)

Add apache ExpiresByType equivalent functionality. The closest thing in nginx at the moment is:

    # CSS and Javascript
    location ~* \.(?:css|js)$ {
      expires 1Y;
      access_log off;
      add_header Cache-Control "public";
    }

which is not ideal as the content type is a more reliable way to identify the type of a file. For example ​http://clientdependency.codeplex.com/ results in a URI of something like /DependcyHandler.axd?asfasdkfjashdfkashdfjkhasdk

I think this would best be done by something like

    # CSS and Javascript
    content_type text/css, text/javascript {
      expires 1Y;
      access_log off;
      add_header Cache-Control "public";
    }

or

    # CSS and Javascript
    for_header "content-type" > text/css, text/javascript {
      expires 1Y;
      access_log off;
      add_header Cache-Control "public";
    }

Documentation clearly states that the proxy module doesn't handle the Vary response header. However, "not handling" can mean a few things, and currently it means things are broken.

Example: nginx as reverse proxy to Apache, and Apache is using mod_deflate to compress the content.

User 1 makes a request for content using a modern browser, which nginx passes on to Apache, and Apache happily returns using a compressed response (Content-Encoding: gzip, Vary: Accept-Encoding).

User 2 makes a request for the same content, but using a brain dead browser (in this case IE, which for 0.5% of users does not accept gzip encoding as we've recently measured). Despite the fact that the browser isn't sending "Accept-Encoding: gzip" to the server, the content is served from nginx's cache in compressed format and the browser receives a response it can't handle.

Expected: nginx should never cache responses that contain the Vary header.

Better Yet, Expected: nginx should properly handle the Vary header and only serve cached versions if the headers match.

Actual: Whatever is cached after the first request is served.

Note: For a long form background on this issue, please see: ​http://www.notthewizard.com/2012/02/27/nginx-reverse-proxy-can-cause-ie-to-fail/

As nginx's design wants to use constant memory allocating a large block of shared memory for session tickets isn't in keeping with that. In RFC5077 it describes how a web server needs to only maintain a small number of aes encryption keys (for allowing tls sessions always available as aes keys expire ) that are shared between all ssl session. The clients will maintain an initialisation vector.

OpenSSL has a callback SSL_CTX_set_tlsext_ticket_key_cb that came out in release 0.9.8h that assists with this function. Can't find its documentation? I wrote some for this: ​http://rt.openssl.org/Ticket/Display.html?id=2697

If client certificates are used then an amount of memory will need to map a client state to the client certificate (which won't be sent when ssl session tickets are used).