Sling Academy
Home/DevOps/NGINX if_modified_since: Explained with examples

NGINX if_modified_since: Explained with examples

Last updated: January 19, 2024

Introduction

The if_modified_since header in NGINX is a pivotal feature for optimizing web performance by leveraging browser caching. This tutorial aims to explain how this header works, along with practical examples that depict the feature’s utilization, from basic to advanced configurations.

What is the if_modified_since Header?

The If-Modified-Since HTTP header is sent by the browser to the server to check if the content has changed since the last time it was fetched. NGINX, a powerful and high-performance web server, can respond to this request by either sending back the full content if it has been modified or a 304 Not Modified status if the content is unchanged.

Basic Example – Enabling if_modified_since

location / {
    if_modified_since before;
    add_header Last-Modified $date_gmt;
}

In the configuration snippet above, we enable if_modified_since by setting it to before. We also add the Last-Modified header with the current date and time in Greenwich Mean Time. This will allow the browser to send the If-Modified-Since request appropriately in subsequent requests based on the given date and time.

Intermediate Example – Configuring Conditional Returns

To deliver a more complex behavior, NGINX allows the use of conditional returns depending on the If-Modified-Since header.

map $http_if_modified_since $ism_conditional {
    default 1;
    '' 0;
}

server {
    location / {
        if ($ism_conditional) {
            return 304;
        }
    }
}

The above configuration introduces the NGINX map directive, which sets a variable based on the presence of the If-Modified-Since header. If it is present and the content has not changed, the server will return a 304 status code. Otherwise, it will proceed to deliver the resource as if it was a regular request.

Advanced Usage – Custom Validation

For more control over the validation process, NGINX supports setting variables and leveraging them within an if directive:

http {
    map $http_if_modified_since $last_modified {
        default $date_gmt;
        '~^(.+)

In this example, a custom map block is defined to set the $last_modified_time variable using a regex that extracts the date from the If-Modified-Since header. The server block then uses an if directive to compare the extracted last modified time with the current GMT date. If they’re equal, it returns a 304 status code. Otherwise, it sends the full content alongside the Last-Modified header for future checks.

Testing and Results

To ensure your NGINX configuration is working as expected, you can simulate requests with the If-Modified-Since header using curl:

curl -I -H "If-Modified-Since: Wed, 24 Feb 2021 07:28:00 GMT" http://yourdomain.com/resource

The output of this command will show whether NGINX returned the full content with a 200 OK status or a 304 Not Modified. It is crucial for validation and debugging your caching strategy.

Conclusion

In conclusion, optimizing web performance requires a good understanding of how conditional requests work. The if_modified_since directive in NGINX is a great tool for managing server responses based on content modifications. Properly configured, it can lead to significant bandwidth savings and faster client experiences. Try out the examples provided and tweak them to best suit your web server’s needs.

$last_modified_time;
}

server {
    location / {
        if ($last_modified_time = $date_gmt) {
            return 304;
        }
        add_header Last-Modified $date_gmt;
    }
}

In this example, a custom map block is defined to set the $last_modified_time variable using a regex that extracts the date from the If-Modified-Since header. The server block then uses an if directive to compare the extracted last modified time with the current GMT date. If they’re equal, it returns a 304 status code. Otherwise, it sends the full content alongside the Last-Modified header for future checks.

Testing and Results

To ensure your NGINX configuration is working as expected, you can simulate requests with the If-Modified-Since header using curl:

The output of this command will show whether NGINX returned the full content with a 200 OK status or a 304 Not Modified. It is crucial for validation and debugging your caching strategy.

Conclusion

In conclusion, optimizing web performance requires a good understanding of how conditional requests work. The if_modified_since directive in NGINX is a great tool for managing server responses based on content modifications. Properly configured, it can lead to significant bandwidth savings and faster client experiences. Try out the examples provided and tweak them to best suit your web server’s needs.

Next Article: NGINX keepalive connections: Explained with examples

Previous Article: NGINX try_files directive: Explained with examples

Series: NGINX Tutorials

DevOps

You May Also Like

  • How to reset Ubuntu to factory settings (4 approaches)
  • Making GET requests with cURL: A practical guide (with examples)
  • Git: What is .DS_Store and should you ignore it?
  • NGINX underscores_in_headers: Explained with examples
  • How to use Jenkins CI with private GitHub repositories
  • Terraform: Understanding State and State Files (with Examples)
  • SHA1, SHA256, and SHA512 in Terraform: A Practical Guide
  • CSRF Protection in Jenkins: An In-depth Guide (with examples)
  • Terraform: How to Merge 2 Maps
  • Terraform: How to extract filename/extension from a path
  • JSON encoding/decoding in Terraform: Explained with examples
  • Sorting Lists in Terraform: A Practical Guide
  • Terraform: How to trigger a Lambda function on resource creation
  • How to use Terraform templates
  • Understanding terraform_remote_state data source: Explained with examples
  • Jenkins Authorization: A Practical Guide (with examples)
  • Solving Jenkins Pipeline NotSerializableException: groovy.json.internal.LazyMap
  • Understanding Artifacts in Jenkins: A Practical Guide (with examples)
  • Using Jenkins with AWS EC2 and S3: A Practical Guide