Expires headers not showing

  • Resolved Kevin Batdorf

    (@kbat82)


    7 years, 2 months ago

    Nginx config looks like this, and everything appears to be working perfectly, except the expires header has no effect. Have they been working elsewhere? Any thoughts?

    location ~* ^/?content/.*\.(png|jpe?g)$ {
	add_header Vary Accept;
	expires 365d;
	if ($http_accept !~* "webp") {
		break;
	}
	try_files
		$uri.webp
		/content/plugins/webp-express/wod/webp-on-demand.php?xsource=x$request_filename&wp-content=content
		;
}
Viewing 14 replies - 1 through 14 (of 14 total)
  • Pothi Kalimuthu

    (@pothi)

    7 years, 2 months ago

    Expires headers mentioned in the above code would work only if webp version of the image is already available. When it is created on-demand, then above expires headers would have zero effect as request is transferred to PHP that is likely handled by another location block. A expires statement is valid only if the request ends in a particular location block. When a request passes through a location block, it doesn’t pick up expires. I hope this help to understand what the above code does.

    Thread Starter Kevin Batdorf

    (@kbat82)

    7 years, 2 months ago

    Thanks @pothi

    So the expires header is useless then in that code block. Any idea how to set the expires header? should it be done via the plugin then?

    (note: the code above comes from the example in the FAQ of this plugin)

    • This reply was modified 7 years, 2 months ago by Kevin Batdorf.
    Pothi Kalimuthu

    (@pothi)

    7 years, 2 months ago

    So the expires header is useless then in that code block. Any idea how to set the expires header?

    In Nginx, we have to create a separate location block only for /wp-content/plugins/webp-express/wod/webp-on-demand.php and then set expires statement there. For example…

    location /wp-content/plugins/webp-express/wod/webp-on-demand.php {
  expires max;
  # other directives to process PHP
}

    If the plugin offers or has such option, yes, please use it.

    Note: I don’t use this plugin. But, I’ve subscribed to posts that have the term “nginx”. So, I came across this topic via email and wanted to put forth my thoughts.

    • This reply was modified 7 years, 2 months ago by Pothi Kalimuthu. Reason: fixed code formatting
    Thread Starter Kevin Batdorf

    (@kbat82)

    7 years, 2 months ago

    Hi @pothi

    I appreciate the assistance. I don’t think there’s an option built in, they just mention it in the FAQs. I added the snippet you suggested and it didn’t work out.

    location ~* /content/plugins/webp-express/wod/webp-on-demand.php {
    expires max;
}

    So maybe it needs some other directives to handle it as you mention. Maybe the plugin author will have a better understanding of that.

    This was the response header for the image (actually similar for all images)

    accept-ranges: bytes
cache-control: max-age=315360000
content-length: 8845
content-type: application/octet-stream
date: Wed, 03 Apr 2019 16:01:40 GMT
etag: "5ca3c5d1-228d"
expires: Thu, 31 Dec 2037 23:55:55 GMT
last-modified: Tue, 02 Apr 2019 20:28:01 GMT
server: nginx/1.11.9
status: 200
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
    Pothi Kalimuthu

    (@pothi)

    7 years, 2 months ago

    Yes, my sample config requires more directives to process PHP.

    I see cache-control: max-age=315360000. What else are you looking for?

    Plugin Author rosell.dk

    (@roselldk)

    7 years, 2 months ago

    @kbat82 actually there is an option build in. You set it in General > Cache-Control header. The PHP script uses that setting.

    • This reply was modified 7 years, 2 months ago by rosell.dk.
    Plugin Author rosell.dk

    (@roselldk)

    7 years, 2 months ago

    That same setting is also used in the .htaccess rules, for redirecting to webps that already exists. – and that is why you still need it in nginx rules for redirecting to existing webps, but do not need it when redirecting to the PHP script

    Thread Starter Kevin Batdorf

    (@kbat82)

    7 years, 2 months ago

    Hi @roselldk @pothi

    I have the Cache-Control header option set, but would like to set the expires header as well, if possible. Regardless of whether it’s beneficial or not to have both, it lowers metric scores. I understand they are just suggestions, but it takes longer to explain the tech to a client then show a score.

    See here: https://gtmetrix.com/reports/bautomation.com/ox6lc4Ia

    Plugin Author rosell.dk

    (@roselldk)

    7 years, 2 months ago

    I see. Bad, bad gtmetrix. The expires header is inferior to cache-control.

    Thread Starter Kevin Batdorf

    (@kbat82)

    7 years, 2 months ago

    I’ll send them an email and see what happens. Maybe they can remove that target. I’ll mark this as resolved. Thanks @roselldk @pothi

    Plugin Author rosell.dk

    (@roselldk)

    7 years, 2 months ago

    But I guess it won’t hurt if I have the script adding expires header too… ?

    • This reply was modified 7 years, 2 months ago by rosell.dk.
    Plugin Author rosell.dk

    (@roselldk)

    7 years, 2 months ago

    If you are in a rush to improve ratings, you can modify plugins/webp-express/wod/webp-on-demand.php manually. It will be overwritten on next update, but perhaps we end up with an update where Expires header is sent too

    Thread Starter Kevin Batdorf

    (@kbat82)

    7 years, 2 months ago

    I’m not in a rush. I’m not sure if having both would be a problem (a quick Google search didn’t help), but maybe have it as an option? Or maybe the choice to use one or the other? I’ll leave that up to you 🙂

    Thanks

    Plugin Author rosell.dk

    (@roselldk)

    7 years, 2 months ago

    Ok. I created an issue in webp-convert to decide what to do: https://github.com/rosell-dk/webp-convert/issues/126

    Thanks for the review 🙂

Viewing 14 replies - 1 through 14 (of 14 total)

The topic ‘Expires headers not showing’ is closed to new replies.

Tags