Fixed Attachments/Proxy output eTags and CloudFlare

[Xon]

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:

  $eTag = $this->_request->getServer('HTTP_IF_NONE_MATCH');
  if ($eTag && $eTag == '"' . $attachment['attach_date'] . '"')

Something like the following would work:

  $eTag = $this->_request->getServer('HTTP_IF_NONE_MATCH');
  if ($eTag && ($eTag == '"' . $attachment['attach_date'] . '"' || $eTag == 'W/"' . $attachment['attach_date'] . '"'))

 

[Mike]

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.

 

[Xon]

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.

 

[Mike]

I've gone ahead and changed this.