No Content-Type in header for webp images

[pamtbaau]

When requesting images, a correct Content-Type is provided in the header for a jpeg image. When requesting a webp image, no Content-Type is provided in the header.

I guess this is an Apache issue and not Grav, but it can be fixed by adding AddType image/webp ".webp" to .htaccess, which could be added by Grav by default.

Or it could be added to Apaches config file for the site, using for example:

<Directory /var/www/html>
   AddType image/webp ".webp"
</Directory>

What do you think? Adding it to .htaccess, or mention it in the docs? Or maybe both...

[Rotzbua]

Better fix this in the server config or better upgrade the server to a newer version.

[pamtbaau]

@Rotzbua

Better fix this in the server config

What makes that a better solution over .htaccess?

or better upgrade the server to a newer version.

I haven't found a reference anywhere stating that a more recent version of Apache has added webp by default. Do you have any pointers?

[Rotzbua]

Better fix this in the server config What makes that a better solution over .htaccess?

For example a common used solution is plesk. Plesk uses a mixture of nginx and apache. Nginx serves the static content to speed up the response time. Nginx does not support .htaccess and you will still receive the image without proper content type.

[pamtbaau]

@Rotzbua, Many, if not most, users of Grav aren't that well versed on infra (I'm one of them) and use plain Apache offered by shared hosting. For these users, .htaccess might be a better choice.

[Rotzbua]

As a infrastructure person you should know that a project based workaround to fix a mime type with .htaccess is not good pattern or solution. A 13 year old image type should be in the default mime configuration.

[rhukster]

There are two wasy to request an image:

1. is via a page fallback in Grav.. ie, an image that exists in a page route that you are accessing via that route.. for example: /blog/some_post/image.webp. This path does not physically exist in the filesystem because it's a grav page path. In this case, Grav forces a download of that image.webp image to your browser and sets the mime type based on the media.yaml configuration file.

2. you access the image with the actual path, in the above example a similar path might be: /user/pages/01.blog/04.some_post/image.webp. If this was the correct path to a physical file in your webserver, then the webserver itself will serve this image before even getting to Grav. If that is the case, and the mime-type is not set or wrong, then it's your webserver that is missing the configuration for that mimetype.