Download files/documents

55 views
Skip to first unread message

Jean-Bernard van Zuylen

unread,
Feb 21, 2014, 5:16:22 AM2/21/14
to taffy...@googlegroups.com
Hi Adam,

I'm adding files upload and download to my API build with Taffy.

For the upload everything is working fine. I've created an endpoint /documents to with the files are sent with a POST. This is OK and works as a charm.

For the download, I'm facing an issue. I've created an endpoint /documents/{filename} with a GET method that get the content of the specified filename (e.g. /documents/mypicture.png) from an external store as a binary object and transfer that binary content to the client using the method streamBinary() and withMime() from the resource.cfc. When I use this, Taffy is throwing me an error: "400 Requested mime type is not supported (png)".

I know that by adding a method "getAsPng" to the my representation class I could bypass this problem but I don't see myself enumerating all possible file extensions... And this method "getAsPng" would even not be used in this case because with streamBinary() doesn't call this method; this method only called with representationOf().

I was thinking of changing code in this way:

- Remove the check on the mime type upfront and let Taffy call the resource.
- Based on the result returned by the resource:
  • In case of representationOf(): check the mime type at the moment and throw an error if the mimetype is not supported (no "getAs..." method).
  • In case of streamFile(), streamBinary(), streamImage(): check the mime type against the value set by the withMime() and throw an error if not the same.
What do you think?

Do you have another way to do this?

Thanks.

Jean-Bernard

Adam Tuttle

unread,
Feb 21, 2014, 9:15:14 AM2/21/14
to taffy...@googlegroups.com
I see what you mean.

As a short term fix, would you be able to try dropping the ".png" from the url? That might work.

I do understand what you're getting at, but the early checking of mime types was done to save server-side effort if the requested format wasn't available (e.g. skip the query step). We could change it as you suggest, but at the cost of some efficiency. Still, inefficiency is probably better than the current state of things.

Checking requested format against withMime() might be problematic. It can be requested two different ways currently: ".png" in the url and an "Accept: image/png" header. Taffy knows to match "image/png" to ".png" requests because the connection is made by the representation class method metadata: getAsPng() taffy:mime="image/png" so without the methods there would be no map.

It might have to be the case that whatever is set by withMime() will be used, requested response format be damned. This would also mean that use of withMime() would be compulsory for streaming back files/binary/images. This is not as big of a deal though, as unless your API deals exclusively with images, you're already required to use it anyway.

Do you agree?

Adam


--
You received this message because you are subscribed to the Google Groups "Taffy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taffy-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Jean-Bernard van Zuylen

unread,
Mar 7, 2014, 9:45:07 AM3/7/14
to taffy...@googlegroups.com
OK, I will try the custom token regex.

Jean-Bernard
 
I'll have to think more about the hook idea, but I had a thought for your images...

If you use a custom token regex that might get you what you need. The way url-format detection works is that if the URI ends with a token, that token (the last one) value is expected _not_ to contain any dots, and then if it does, then the superfluous stuff is considered a requested response format.

If you specify a custom token regex like this: {img:[a-zA-Z0-9_\.\-]+\.(png|jpg|jpeg|gif)} 

...then that might act like you're expecting by allowing any number of dots in the token value and expecting it to end with an image file extension but not using that as a requested format.

Adam

On Fri, Mar 7, 2014 at 9:25 AM, Jean-Bernard van Zuylen <jbvan...@hotmail.com> wrote:
Hi Adam,

Dropping the file extension ".png" from the url works, but I prefer to keep the filename as it was. So I commented out the check on the mimetype on my local instance and it worked so far.
But today, I faced another issue with filenames with several dots like "mypicturev1.1.png" where Taffy is taking "1.png" as extension instead of ".png".
So I think I will implement the download part outside of Taffy because I see no easy way to fix this.

I agree with you that early checking of mime types saves server-side effort in case the format is supported and this is a good thing.

Maybe we could give the developer the possibility to do the check in the "onTaffyRequest" and then indicate to Taffy to not do the check again.

Or by adding some sort of hook. For example a method in the resource.cfc with the current checks but the developer can override this method in all or some of his resources. This method would be called by Taffy before executing the real request.

Jean-Bernard

Jean-Bernard van Zuylen

unread,
Mar 7, 2014, 12:22:40 PM3/7/14
to taffy...@googlegroups.com
Hi Adam,

It's work perfectly!

I used this regex: {name:.+} to make sure the token (which is the last one) catches all the ending characters from the URL.

Thanks for your help.

Jean-Bernard


Le vendredi 7 mars 2014 15:45:07 UTC+1, Jean-Bernard van Zuylen a écrit :
OK, I will try the custom token regex.

Jean-Bernard
 
I'll have to think more about the hook idea, but I had a thought for your images...

If you use a custom token regex that might get you what you need. The way url-format detection works is that if the URI ends with a token, that token (the last one) value is expected _not_ to contain any dots, and then if it does, then the superfluous stuff is considered a requested response format.

If you specify a custom token regex like this: {img:[a-zA-Z0-9_\.\-]+\.(png|jpg|jpeg|gif)} 

...then that might act like you're expecting by allowing any number of dots in the token value and expecting it to end with an image file extension but not using that as a requested format.

Adam

Adam Tuttle

unread,
Mar 7, 2014, 12:40:14 PM3/7/14
to taffy...@googlegroups.com
Cool, glad to hear it!

Adam


--
You received this message because you are subscribed to the Google Groups "Taffy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taffy-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages