Fixed Attachments/Proxy output eTags and CloudFlare

Xon

Well-known member
It looks like attachment's eTags are appended with "W/" if behind Cloudflare, to mark them as weak eTags.

This causes the eTag check to fail:
Code:
  $eTag = $this->_request->getServer('HTTP_IF_NONE_MATCH');
  if ($eTag && $eTag == '"' . $attachment['attach_date'] . '"')

Something like the following would work:
Code:
  $eTag = $this->_request->getServer('HTTP_IF_NONE_MATCH');
  if ($eTag && ($eTag == '"' . $attachment['attach_date'] . '"' || $eTag == 'W/"' . $attachment['attach_date'] . '"'))
 
I'm not actually seeing CloudFlare changing the ETags when I test. I can't find any reference to this via Google or as an obvious setting in CF. Do you have an example where I can see this? (Is it perhaps a side effect of explicit caching rules in CF?) It's a simple fix to support both and it shouldn't harm anything, but I'd like to be able to reproduce it and understand it first.
 
I'm not actually seeing CloudFlare changing the ETags when I test. I can't find any reference to this via Google or as an obvious setting in CF. Do you have an example where I can see this? (Is it perhaps a side effect of explicit caching rules in CF?) It's a simple fix to support both and it shouldn't harm anything, but I'd like to be able to reproduce it and understand it first.
I've written an add-on which serves SVG files as an attachment, and I've only seen it happen with SVG so far. I haven't seen this triggered with other content types.

The attachment view changes are quite simple, and involve sending the right mime-type and content-disposition and I've got a CF page rule explicitly disabling caching to my testing site which is where I saw this.

And like you, I couldn't find any documentation or references about this behaviour.
 
Top Bottom