WP-Appbox Cached Images don’t have content-type in response header

  • Hello,

    I am working hard in optimizing performances on my blog.

    I found that all WP-Appbox cached images are not cached by Cloudflare CDN.

    I suppose this is due to the fact that WP-Appbox cached images are not providing “content-type” inside the response header.

    See the following example:

    pi@RaspberryPi:~ $ curl -I https://lamiacasaelettrica.com/wp-content/cache/wp-appbox/900a521d956da14d4acc3e5ef0d1da88/ai-345884adbfea6278586711b6a3a1305e    HTTP/2 200
date: Sat, 21 Aug 2021 11:04:34 GMT
cf-ray: 6823619d0e4f599b-MXP
cache-control: max-age=31536000
etag: W/"30d4d2-322b-5bf1e0c9d5bf9-gzip"
last-modified: Sun, 04 Apr 2021 04:31:05 GMT
strict-transport-security: max-age=31536000; includeSubDomains
vary: Accept-Encoding,User-Agent
cf-cache-status: MISS
cf-apo-via: origin,nohtml
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
referrer-policy: no-referrer-when-downgrade
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=K3l%2BRyx82lNjX8YU0GcTrj%2FB8Cxqwy0XVxtWk6oK2xG0RmuPDI0XVQ9zt2Wt8phORRhXF2qmo7QysdP5c2Czwkd6fO9AJCKB%2B5i7yn3yA5MZhPOoKHZ%2FIs4jlKkQNSgdqrd2xwoY16g%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400

    Is it possibile to check and eventually fix it?

    Thanks !

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author Marcelismus

    (@marcelismus)

    Yes, the file extension is missing due to different formats and the mechanics itself. But no, I have not yet found a solution that works for all stores (and their various “i/o tests”). However, the MIME type should be able to be read correctly. If it’s something else, I can’t say, since I don’t use Cloudflare.

    • This reply was modified 3 years, 3 months ago by Marcelismus.
    Thread Starter emilianomaina

    (@emilianomaina)

    Hello @marcelismus

    but cannot you “simply” copy the response header content-type (not the file extension) received from the store when you fetch the images?

    See some examples:

    Apple Store

    pi@RaspberryPi:~ $ curl -I https://is1-ssl.mzstatic.com/image/thumb/Purple115/v4/6e/9c/1e/6e9c1e54-3350-42bc-d328-6ca56836f3a8/AppIcon-0-0-1x_U007emarketing-0-0-0-10-0-0-sRGB-0-0-0-GLES2_U002c0-512MB-85-220-0-0.png/460x0w.webp
HTTP/2 200
server: ATS/9.0.3
content-type: image/webp

    Google Store

    pi@RaspberryPi:~ $ curl -I https://play-lh.googleusercontent.com/AUxyD7DRhTvidEulSUlVP7-_pVi_zdbcaDVq2KdvorPd7lQAG2IhBG9coCOlo0038pGA=s360-rw
HTTP/2 200
access-control-expose-headers: Content-Length
etag: "v1"
expires: Tue, 24 Aug 2021 06:04:58 GMT
content-disposition: inline;filename="unnamed.webp"
content-type: image/webp

    The you store the image with the extension corresponding to the store anwser in order to tell to wordpress server how to properly anwser to clients.

    Plugin Author Marcelismus

    (@marcelismus)

    The image is saved as it is on the stores, there are no conversations or changes (MIME type is recognized correctly). And as far as I know, an image does not have a response header, that is provided by the server ??

    • This reply was modified 3 years, 3 months ago by Marcelismus.
    Thread Starter emilianomaina

    (@emilianomaina)

    Understood.

    What I suggest is to add extension to the file, if missing, when you cache on your server based on the response header provide by the app store.

    In this way your server will know which response header to provide.

    Plugin Author Marcelismus

    (@marcelismus)

    Sounds simple – but leads(s) to problems with some stores, because partly different formats were output and for example Google does not deliver a “real” file (url). An additional query is unfortunately also not so easy possible – there would quickly start the bot protection of Google and Co. for medium pages.

    To change the mechanics in the plugin would currently also rather a matter of weeks to months. Try to intercept the query and deliver the header yourself – if additional caching via Cloudflare is necessary. Currently not prioritized.

    • This reply was modified 3 years, 3 months ago by Marcelismus.
    Thread Starter emilianomaina

    (@emilianomaina)

    From the logical point of view it is simple.

    App store already provides you:
    – file name (it’s the request itself performed to retrive the image)
    – image type (response header feld content-type)
    – actual response

    No additional query to perform.

    Today you store actual response using file name.

    Tomorrow you store actual response using file name + adding extension (based on content-type) if file name doesn’t have yet an extension.

    In my opinion as of today the image caching feature can only decrease performances because any caching layer would be missing a key parameter (content type is reccomended by http specifications).

    Plugin Author Marcelismus

    (@marcelismus)

    As I said, it’s not enough to just attach the extension – because with the current mechanics (no cURL), saving the Google images (and other actions regarding screenshots) is not possible without further modification. Also with regard to already saved images.

    There will be a change to the mechanics only with a new bigger update (and no idea if it’s working with CloudFlare); but this will no longer be 2021.

    • This reply was modified 3 years, 3 months ago by Marcelismus.
Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘WP-Appbox Cached Images don’t have content-type in response header’ is closed to new replies.