You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
User contributed images are issued a random id1 and uploaded directly to the S3 media bucket. They are publicly accessible via a URL of the form:
/media/<id>
If the request is made of the form:
/media/<id>/<size>
Either a scaled version will be found by that key and immediately served, or a redirect will be issued to a scaling function that will determine whether the scaling request is valid, and if it is will download the image from the media bucket, scale it, and place the scaled image into the bucket under the scaled version retrieval key. If successful, it will then return a redirect to the scaled image.
Logic regarding which object resize requests will be carried out can be implemented inside the scaling function.
My thoughts are currently that <size> should refer to the object's vertical dimension.
Footnotes
Identifying a file by the hash of its contents would arguably be better. However, currently the id is assigned before the image has been uploaded, at which point the contents wouldn't be known even by the client. To make this robust, a provisional id would need to be issued for the new upload, and then the server would need to verify the contents and assign a content-based id to the uploaded image. Refer to the get-upload-link function to see initial step in the image upload process. ↩
The text was updated successfully, but these errors were encountered:
User contributed images are issued a random id1 and uploaded directly to the S3 media bucket. They are publicly accessible via a URL of the form:
/media/<id>
If the request is made of the form:
/media/<id>/<size>
Either a scaled version will be found by that key and immediately served, or a redirect will be issued to a scaling function that will determine whether the scaling request is valid, and if it is will download the image from the media bucket, scale it, and place the scaled image into the bucket under the scaled version retrieval key. If successful, it will then return a redirect to the scaled image.
Logic regarding which object resize requests will be carried out can be implemented inside the scaling function.
My thoughts are currently that
<size>
should refer to the object's vertical dimension.Footnotes
Identifying a file by the hash of its contents would arguably be better. However, currently the id is assigned before the image has been uploaded, at which point the contents wouldn't be known even by the client. To make this robust, a provisional id would need to be issued for the new upload, and then the server would need to verify the contents and assign a content-based id to the uploaded image. Refer to the
get-upload-link
function to see initial step in the image upload process. ↩The text was updated successfully, but these errors were encountered: