Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use correct MIME type for S3 object responses #21

Closed
codewithkyle opened this issue Aug 18, 2022 · 1 comment
Closed

Use correct MIME type for S3 object responses #21

codewithkyle opened this issue Aug 18, 2022 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@codewithkyle
Copy link
Owner

Cloud Storage

Objects are stored as application/octet-stream when they are uploaded to S3 or DO Spaces. Since we don't have a local file to pull a MIME type from and we don't want to add extra IO overhead (write + read + delete) on each response we just pass the S3 SDK's response content type as our own.

Jitter Implementation Limitations

One of the main limitations for storing the transformed image's MIME type when using S3/DO Spaces is finding a place where we could actually stash the information. Jitter doesn't use the database so when an image is requested Jitter creates a hash of the source image's ID and another hash based on the transformation settings. We then combine both hashes to create a unique identifier {ID}-{SETTINGS}. The unique identifier is saved as an empty file on the file system using PHP's touch() function. If the file exist we know we can get the object from S3/Spaces. Using the S3 SDK we get the object and pass the SDK response content back to the frontend.

Possible Solutions

The unique identifier logic could be updated to be {ID}-{SETTINGS}-{ENCODED MIME TYPE} and wouldn't break backwards compatibility. Then when an image is pulled from S3/Spaces we could split on the - and decode the MIME. I don't really like the idea of using part of the unique identifier for stashing the MIME type since it sits on the file system and could be tampered with. I'm by no means a security expert but something feels wrong about parsing this data and including it in the response headers.

Another solution could be to try and change the way we touch() the file system. We could try to enforce a specific MIME type when the file is created so we could use the same mime_content_type function like we do with locally stored images.

I can see how the application/octet-stream MIME type could be an issue, such as when you want to link someone directly to an image. The expected behavior is that the browser should render the image but instead it triggers a download.

Originally posted by @codewithkyle in #20 (comment)

@codewithkyle codewithkyle self-assigned this Aug 18, 2022
@codewithkyle codewithkyle added the bug Something isn't working label Aug 18, 2022
@codewithkyle
Copy link
Owner Author

This was an easy fix. S3 and DO Spaces let us set the 'ContentType' value when uploading an object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant