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
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.
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'stouch()
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 samemime_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)
The text was updated successfully, but these errors were encountered: