AstroLog PIR®
All WordPress sites entries

The WhatsApp previews and the malformed 206

HighWordPress sites 2 min readBy Christopher W
TL;DR: During inaugural-convention week, WhatsApp link previews served days-old data. Root cause found two layers deep: our og:image was a WebP (fixed on our side), but the transfer layer was also malformed - ranged HTTP/2 requests came back as HTTP 206 with an impossible "content-encoding: gzip,br" header and a truncated body (curl error 61). WPX's Denis S. disabled W3 Total Cache's GZIP compression, and previews came back to life hours before the streams went live.

Source: WPX ticket #733952, “Malformed Content-Encoding on ranged HTTP/2 responses breaks Meta/WhatsApp crawler” (WPX support portal).

Read the full story →

The symptom that looked like caching

The new convention live-stream hub wouldn’t preview in WhatsApp: stale, days-old scrape data, falling back to the bare domain. The Sharing Debugger insisted on curl error 61 (BAD_CONTENT_ENCODING) with response code 206.

The probe that cracked it: plain GETs returned perfect 200s with valid gzip; any request carrying a Range header came back as HTTP 206 with a content-encoding: gzip,br header and a body truncated to the range length - an undecodable stream. Meta’s crawler does exactly those resumed fetches, chokes mid-transfer, and falls back to its last successful scrape. The same probe even returned a 412 on a later try: unstable at the edge, not in the cache. Purging W3 Total Cache and Autoptimize changed nothing.

The two fixes

  1. Ours: the og:image was a WebP, which WhatsApp’s renderer can’t display, and an SEO-plugin cache held the old image after it was corrected to a JPEG. Once both were fixed, WhatsApp fetched the page fresh on its own.
  2. Theirs: Denis S. took wp-admin access via a temporary wpx user (created and removed cleanly - attribution requested and honored), investigated, and disabled W3 Total Cache’s GZIP compression.

The verification

Re-tested from our side before the weekend: fresh loads returned clean 200s with a single correct content-encoding: gzip; ranged requests returned well-formed 206s serving raw bytes with proper Content-Range headers; WhatsApp previews rendered correctly, including the new convention schedule image.

One line for the record: if W3TC’s GZIP compression is ever re-enabled, re-test ranged responses first. The fix lives in a checkbox someone could innocently flip.

The preview was never the problem; the pipe was.