Cachify plugin breaks Facebook sharing

Hi @markhowellsmead,

the old post is now 7 months old without any answer, but I’d assume the reported issue is the very same: Facebook always gets HTTP 206

First pleas note that I do not have any clue what the FB debugger does. Nevertheless let’s try tracking down the issue.

According to the HTML signature you’re using HDD caching.
Furthermore from reading the sources and plugin files, you’re using WP 5.8.2 with Cachify 2.3.2.

Next, let’s have a look into the response headers for cached and uncached requests (headers with different contents only):

Cached:

Content-Type: text/html
Last-Modified: Sat, 20 Nov 2021 18:16:13 GMT
Etag: "199a8-61993b6d-97ee3b82b6c57da1;;;"
Accept-Ranges: bytes
Content-Length: 104872

Uncached:

Content-Type: text/html; charset=UTF-8
X-Pingback: https://permanenttourist.ch/xmlrpc.php
Link: <https://permanenttourist.ch/wp-json/>; rel="https://api.w.org/"
Link: <https://permanenttourist.ch/wp-json/wp/v2/posts/62742>; rel="alternate"; type="application/json"
Link: <https://permanenttourist.ch/?p=62742>; rel=shortlink

When static content (i.e. cached HTML file) is served, the webserver accepts partial content, indicated by the Accept-Ranges header (MDN), so 206 codes are probably fine when partial content is actually requested.

E.g. requests like

$ curl -i -H 'Range: bytes=0-1024' https://permanenttourist.ch/2021/11/axalp-in-the-snow/
$ curl -i -H 'Range: bytes=1024-2048' https://permanenttourist.ch/2021/11/axalp-in-the-snow/

do exactly what they are expected to do, deliver first and second 1kB-slice with status 206 and header Content-Range: bytes 0-1024/104872.

Second the Content-Type header (MDH) is missing a charset value, that’s what might lead to a bad encoding error.

Are you in control of any webserver settings?
Do you have access to server logs that indicate the request headers the FB debugger uses?

Try opening a cached HTML file from the wp-content/cache/cachify/ directory and verify the encoding in a text editor of choice.

Second thing I would try is placing an arbitrary HTML file anywhere on the server and see what the FB debugger does with that.

Cheers,
Stefan

• This reply was modified 4 years, 6 months ago by Stefan Kalscheuer. Reason: clean up the mess due to missing braces
• This reply was modified 4 years, 6 months ago by Steven Stern (sterndata).

Thanks for your analysis. I totally forgot about the pre-compressed stuff, seems obvious though.

Just checked GZ files generated by Cachify, they seem to be valid, so the PHP GZip module is not broken – at least in my test container.

My suspicion is that the response is missing the expected headers, so the compressed content is transmitted, but a strict client fails to read it without proper indication. (browsers do forgive quite a lot, so very likely no human visitor ever noticed an error)

I don’t have an Apache+WP site on hand to verify. If I’m right, an additional directive like this should fix the problem (documentation should be updated in this case):

<FilesMatch "\.html\.gz$">
    Header append Content-Encoding gzip
    Header append Vary Accept-Encoding
</FilesMatch>

Your site does provide the correct headers now that the server handles compression on-the-fly. (didn’t test that case yesterday)