Get content type and length with store requests

[ZeroBeeOne]

Hi there,

I noticed, based on the documentation, that a call to ->store() will not return content-length and content-type with the HTTP response. Of course this is related to the fact that binary data is not being returned, so these headers would not perform their normal purpose - is there a chance the API could return this information in some other header for these calls though? as it is, the Tinify\Result object returned by the call to ->store() cannot return meaningful values for the methods: ->size(), ->mediaType() or ->contentType(). Obviously these would need to be modified if the data were somewhere other than the content-length and content-type headers, but right now there is no way, for instance, to tell the compression ratio of an image uploaded directly to S3 without using an extra compression and extra bandwidth to download the whole image directly, just to get the few bits in those headers (Or to download it from Amazon after the call to ->store() succeeds and parse the data from there). Either of these workarounds negate the benefit of being able to store compressed images directly to Amazon though.

[mattijsvandruenen]

Hi,

Thanks for your comment and feedback. You're correct that a call to ->store() doesn't include the Content-Length and Content-Type response headers that correspond to the compressed image. The Tinify\Result object returned by it will therefore indeed not return any useful values for ->size() and ->mediaType().

You can however still get the information you're interested in by calling ->result()->size() and ->result()->mediaType() on the $source object without needing an extra compression. This call will do a GET request to download the image from our temporary image storage, so it will use some bandwidth. Code wise, this should be the easiest and cleanest way to currently get the data you're interested in.

Does that help you?

[ZeroBeeOne]

Oh ok great, thanks, so to confirm it's the creation of the $source object that causes an image compression, not the $result? I'd actually already coded around it anyway by making a HEAD call to the returned location on Amazon, which is a bit more bandwidth conservative anyway, so I'll probably keep it, but it's helpful to know that for future reference.

[mattijsvandruenen]

Any call to fromFile, fromBuffer and fromUrl on \Tinify\ will already cause a compression to take place. A call to ->result() on the output of the previous call will simply download the compressed image, and make the size and type returned as response headers available under ->size() and ->mediaType().