Regarding Enable direct redirection to existing converted images

I suggest you contact your host and tell them that it appears that they haven’t installed “mod_headers”. The rules you got from them actually resembles the ones that WebP Express creates very closely. And those rules you got there ALSO requires mod_headers to work properly. As the WebP Express warning says: Without mod_headers, the Vary:Accept header isn’t send. The consequence is that some proxy servers in larger companies that uses caching sends a cached webp to a browser that does not support webps.

Can you provide an URL to the site (after enabling redirection). I can then inspect the response headers to see if the vary: Accept is sent.

Hi,

The redirection is enabled. However, not all the images have the corresponding WebP. You can check the following URLs with existing WebP:

https://www.craftesy.com/store/
https://www.craftesy.com/wooden-dry-fruit-tray-two-bowls/
https://www.craftesy.com/wooden-marble-stone-chess-set-board/

For the rest of the pages, the plugin will create the WebP First.

Thanks

Hi,

Viewing the response headers of this image:
https://www.craftesy.com/wp-content/uploads/2019/08/swan-bowl-tray-white-metal-silver-duck-450×450.jpg

I see:
cache-control: public, max-age=604800
content-length: 30152
content-type: image/webp
date: Tue, 13 Aug 2019 19:19:59 GMT
etag: “75c8-5d51249c-2eac4037a36444d5;;;”
expires: Tue, 20 Aug 2019 19:19:59 GMT
last-modified: Mon, 12 Aug 2019 08:34:36 GMT
server: LiteSpeed
status: 200

The “content-type: image/webp” tells us that the image is served as webp. So far, so good.

However, there is no “vary: Accept” header (WebP Express was right about that problem). You should try to fix that problem. Try contacting your host. Tell them that it appears that “mod_headers” isn’t enabled because you don’t get the response header. You can point them to this topic.

Hi,

I have talked the host and they confirmed that mod_header is already installed.

However, proceeding that I want to clear a doubt regarding the plugin.
After enabling direct redirection, below is the .htaccess

# BEGIN WebP Express
# The rules below are a result of the WebP Express options, WordPress configuration and the following .htaccess capability tests:
# - mod_header working?: no
# - pass variable from .htaccess to script through header working?: no
# - pass variable from .htaccess to script through environment variable working?: yes
<IfModule mod_rewrite.c>
  RewriteEngine On

  # Redirect to existing converted image in cache-dir (if browser supports webp)
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME} -f
  RewriteCond %{DOCUMENT_ROOT}/wp-content/webp-express/webp-images/doc-root/wp-content/$1.$2.webp -f
  RewriteRule ^/?(.+)\.(jpe?g|png)$ /wp-content/webp-express/webp-images/doc-root/wp-content/$1.$2.webp [NC,T=image/webp,E=EXISTING:1,L]

  # WebP Realizer: Redirect non-existing webp images to webp-realizer.php, which will locate corresponding jpg/png, convert it, and deliver the webp (if possible) 
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^/?(.+)\.(webp)$ /wp-content/plugins/webp-express/wod/webp-realizer.php [E=DESTINATIONREL:wp-content/$0,E=WPCONTENT:wp-content,NC,L]

  # Redirect images to webp-on-demand.php (if browser supports webp)
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME} -f
  RewriteCond %{QUERY_STRING} (.*)
  RewriteRule ^/?(.+)\.(jpe?g|png)$ /wp-content/plugins/webp-express/wod/webp-on-demand.php?%1 [E=REQFN:%{REQUEST_FILENAME},E=WPCONTENT:wp-content,NC,L]

</IfModule>
<IfModule mod_mime.c>
  AddType image/webp .webp
</IfModule>

# END WebP Express

Since direct redirection is enabled yet no mod_header condition or the rule are there in the htaccess.
So without the condition how would you determine the Vary Accept header?

Now let’s come back about the mod_header installed or not concern.

The host added the below rule on the top of plugin’s htaccess, i.e. before the code mentioned above:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self' *.facebook.com;frame-ancestors 'self' *.facebook.com;script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:;base-uri 'none';object-src 'none';"
</IfModule>

This rule is still present there to let you check in the browser. So definitely the mod_header is enabled.

So what else can be done? All rules are in front of you.
https://www.craftesy.com

Thanks

• This reply was modified 5 years, 3 months ago by Amit Sonkhiya.

HI,

I think we’re close to the solution. Would you check my previous comment?

Concern: mod_header is installed, direction redirection is complaining about it.

Thank you

Hi again,

I have released 0.15.0 which includes self-test and diagnosis of the redirects. Please click the “Live test” next to the redirect rules that you are using. It will make an external requests and analyze the responses and report any problems.

Sorry, I marked as resolved by accident. It seems I cannot change it back to unresolved. But perhaps 0.15.0 solves it for you?

Hi @roselldk

I’ve version 0.17.1 installed. I’m still getting the warning:

It seems your server setup does not support headers in .htaccess. You should either fix this (install mod_headers) or deactivate the “Enable direct redirection to existing converted images?” option. Otherwise the Vary:Accept header will not be added and this can result in problems for users behind proxy servers (ie used in larger companies)

Below is the Live Test result:

Check that browsers supporting webp gets the WEBP when the JPEG is requested

Response headers:
- cache-control: public, max-age=604800
- expires: Sat, 12 Oct 2019 14:24:46 GMT
- content-type: image/webp
- last-modified: Sat, 05 Oct 2019 14:24:46 GMT
- etag: "1b34-5d98a7ae-32210add40c556e;;;"
- accept-ranges: bytes
- content-length: 6964
- date: Sat, 05 Oct 2019 14:24:46 GMT
- server: LiteSpeed
- content-security-policy: default-src 'self' .facebook.com;frame-ancestors 'self' .facebook.com;script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:;base-uri 'none';object-src 'none';
- x-webp-express: Redirected directly to existing webp
- alt-svc: quic=":443"; ma=2592000; v="39,43,46", h3-22=":443"; ma=2592000

Warning: We did not receive a Vary:Accept header.

Check that browsers not supporting webp gets the JPEG

Response headers:
- cache-control: public, max-age=604800
- expires: Sat, 12 Oct 2019 14:24:46 GMT
- content-type: image/jpeg
- last-modified: Sat, 05 Oct 2019 14:24:46 GMT
- etag: "c7b-5d98a7ae-e6fd41a6b8fa4523;;;"
- accept-ranges: bytes
- content-length: 3195
- date: Sat, 05 Oct 2019 14:24:46 GMT
- server: LiteSpeed
- content-security-policy: default-src 'self' .facebook.com;frame-ancestors 'self' .facebook.com;script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:;base-uri 'none';object-src 'none';
- vary: Accept,Accept
- alt-svc: quic=":443"; ma=2592000; v="39,43,46", h3-22=":443"; ma=2592000

Alrighty. We got the jpeg. Great!.

So the browser that supports webp isn’t still getting the very-accept header.

Now I’m sure that the mod_header is installed. You see the content-security-policy header in the response, that is inside the condition checking the existence of mod_header and placed at the very top of the .htaccess.

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self' *.facebook.com;frame-ancestors 'self' *.facebook.com;script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:;base-uri 'none';object-src 'none';"
</IfModule>
<IfModule mod_rewrite.c>
  RewriteEngine On

  # Redirect to existing converted image in cache-dir (if browser supports webp)
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME} -f
  RewriteCond %{DOCUMENT_ROOT}/wp-content/webp-express/webp-images/doc-root/wp-content/$1.$2.webp -f
  RewriteRule ^/?(.+)\.(jpe?g|png)$ /wp-content/webp-express/webp-images/doc-root/wp-content/$1.$2.webp [NC,T=image/webp,E=EXISTING:1,L]

  # Redirect images to webp-on-demand.php (if browser supports webp)
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME} -f
  RewriteRule ^/?(.+)\.(jpe?g|png)$ /wp-content/plugins/webp-express/wod/webp-on-demand.php [NC,L,E=REQFN:%{REQUEST_FILENAME},E=WPCONTENT:wp-content]

  # Make sure that browsers which does not support webp also gets the Vary:Accept header
  # when requesting images that would be redirected to webp on browsers that does.
  <IfModule mod_headers.c>
    <FilesMatch "(?i)\.(jpe?g|png)$">
      Header append "Vary" "Accept"
    </FilesMatch>
  </IfModule>

</IfModule>

What is conflicting in the plugin? How to rectify it?

Thanks

• This reply was modified 5 years, 1 month ago by Amit Sonkhiya.

The plugin only uses the result of the mod_headers test in regards to Cache-Control. The Cache-Control header is always added (when set). On systems where mod_headers appears not to be working, the following fallback is added (with the appropriate time):

<IfModule !mod_headers.c> 
  <IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/webp "access plus 1 days"
  </IfModule>
</IfModule>

Are you adding the rules manually?

You should be seeing this in the .htaccess files located in the directories that contains webps:

# Rules for handling requests for webp images
# -------------------------------------------

# Set Vary:Accept header if we came here by way of our redirect...
# The purpose is to make proxies and CDNs aware that the response varies with the Accept header
<IfModule mod_headers.c>
...

That is: The above should be inside wp-content/webp-express/webp-images/.htaccess. If you have set “Destination folder” to “mingled”, it should also be in wp-content/uploads/.htaccess.

To quickly and easily get vary:accept header for jpegs and pngs served as webps, add this to a .htaccess that contains webps, ie. wp-content/.htaccess (put it outside webp-express section):

<IfModule mod_headers.c>
  <FilesMatch "(?i)\.(jpe?g|png)$">
    Header append "Vary" "Accept"
  </FilesMatch>
</IfModule>

(though it ought to be there in the webp-express section)

• This reply was modified 5 years, 1 month ago by rosell.dk.
• This reply was modified 5 years, 1 month ago by rosell.dk.

I see you get this header:
x-webp-express: Redirected directly to existing webp

This must have been produced from these rules:

# Set Vary:Accept header if we came here by way of our redirect, which set the ADDVARY environment variable
# The purpose is to make proxies and CDNs aware that the response varies with the Accept header
<IfModule mod_headers.c>
  <IfModule mod_setenvif.c>
    # Apache appends "REDIRECT_" in front of the environment variables defined in mod_rewrite, but LiteSpeed does not
    # So, the next lines are for Apache, in order to set environment variables without "REDIRECT_"
    SetEnvIf REDIRECT_EXISTING 1 EXISTING=1
    SetEnvIf REDIRECT_ADDVARY 1 ADDVARY=1

    Header append "Vary" "Accept" env=ADDVARY

    # Set X-WebP-Express header for diagnose purposes
    Header set "X-WebP-Express" "Redirected directly to existing webp" env=EXISTING
  </IfModule>
</IfModule>

You must have these rules somewhere… Probably in wp-content/webp-express/webp-images/.htaccess.

It would seem that the “ADDVARY” environment variable isn’t set.
Probably it is because you are on Litespeed. I haven’t been testing on Litespeed for a while.

But that is truly strange.
We have:

Header append "Vary" "Accept" env=ADDVARY
Header set "X-WebP-Express" "Redirected directly to existing webp" env=EXISTING

And you have the “X-WebP-Express” header set but not the Vary.
So it seems the EXISTING env variable is set, but not ADDVARY.
However, both are set in the same line!

In the rules in .htaccess’es containing “source” images (original, unconverted images) we have:

RewriteRule ^/?(.+)\.(jpe?g|png)$ /wp-content/webp-express/webp-images/doc-root/wp-content/uploads/$1.$2.webp [NC,T=image/webp,E=EXISTING:1,E=ADDVARY:1,L]

Which host are you using? https://www.hostinger.com/ ? On which plan? I shall contact them and ask if they would want to provide an account for me for testing WebP Express.

I just contacted Hostinger with a request…