Page MenuHomePhabricator

File transform regeneration should not rely on passing a query string to a CDN'able resource
Open, WishlistPublic

Description

Currently, Configuring a File Domain states that (for CloudFront):

Most settings can be left at their default values

However, whilst regenerating some broken thumbnails for a bunch of macros (see T12950) I discovered a Phabricator bug that results from having CloudFront not forward the query string to the origin backend (which is the default behavior when configuring CloudFront through the AWS console).

Basically, it isn't currently possible to regenerate a file transformation if CloudFront isn't forwarding the query string. A file transformation request looks something like this: /file/xform/pinboard/PHID-FILE-nd5ns3k37cxdymd4cy6o/f7cvgcw4dvjkpvacwfah/?regenerate. If CloudFront isn't forwarding the query string, the the backend will only see /file/xform/pinboard/PHID-FILE-nd5ns3k37cxdymd4cy6o/f7cvgcw4dvjkpvacwfah/. If the file doesn't have a transformation yet then this is fine because one will be generated. If, however, the file already has the specified transformation (but it needs to be regenerated for some reason), then it is not possible to regenerate the thumbnail.

We should maybe update the CloudFront documentation to state the query strings should be forwarded to the backend? Alternatively, we could instead just ensure that this particular URL points to the base domain rather than the alternate file domain. This is probably reasonable given that the regenerate request isn't cacheable anyway.

Event Timeline

epriestley renamed this task from CloudFront documentation should recommend forwarding query string to File transform regeneration should not rely on passing a query string to a CDN'able resource.Aug 3 2017, 2:52 PM
epriestley triaged this task as Wishlist priority.
epriestley added a subscriber: epriestley.

I retargeted this; I think the proposed solution is not the best solution we can find to the problem.

Yep, agreed that the re-targeted proposal is a better solution... I had just assumed that this was a documentation oversight.