Image creation and broken images on first request

[ryanhinkel]

We currently images appear broken the first time they are requested. This happens when an image is requested at a constrained size. It happens because the new image takes a moment to resize and put on S3. In the meantime, S3 returns a 403 Forbidden.

[ryanhinkel]

I am reissuing this, because it is currently something that keeps me up at night.

[ryanhinkel]

Related: currently the endpoint /image/ is hit and returns a 302. This seems to prevent caching in Chrome.

This question has come up before, how will a 301 affect this issue.

[ryanhinkel]

Would this be solved if the /image/ endpoint could check for job completion and return a 501 Not Implemented if it does not?

[ryanhinkel]

501 Not Implemented The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API).

[ryanhinkel]

The problem with a 502 is that the browser does not cache the image. Thus, the UI feels much slower. This is on the border of being an unacceptable problem. Also, at the point I want to add control over image size to the UI, this problem becomes worse.

This is proving to be a hard one.

[di]

This can be fixed by doing long polling on the backend for the blitline job. https://www.blitline.com/docs/polling

The initial request will be slower but it will not fail.

A 501 is not appropriate here.

[di]

Also, from #85:

Tumblr uses a 302. We should probably give a cache expiration time for it, though.

If we give a cache expiration header, the cache will not expire until the expiration date.

[di]

I added #109 to address the caching issue which is separate from this issue.

[di]

"It's so good... it's so good." —@ryanhinkel