search

silkapp / rest

Packages for defining APIs, running them, generating client code and documentation.
http://silkapp.github.io/rest
390 stars 52 forks source link

Getting an uploaded file #137

Open jonkri opened 9 years ago

jonkri commented 9 years ago

When uploading files, the ByteString looks to include the complete request, including headers and whatnot. The ByteString will look something like this:

file

This surprised me a bit - I thought I would be getting the uploaded file's content.

I uploaded the file like so:

curl --header "Content-Type: application/octet-stream" --form upload=@big-buck-bunny_trailer.webm --request POST <URL>

How would a user go about extracting the actual file?

Might be related to #68 and #102.

Thanks!

hesselink commented 9 years ago

We don't currently handle form posts, as far as I know. If you use a file input type, we expect just the file. So in curl you should use --data-binary instead of --form.

hesselink commented 9 years ago

The mentioned tickets are about multipart input with multipart/mixed type. For forms, you can use multipart/form-data, which is slightly different, or application/x-www-form-urlencoded, which is completely different. The returned data in Haskell for forms should probably also be different, since the values have an associated (field) name, where they don't in "normal" multipart.

Also note that accepting form posts in an API might be unsafe, since you can do cross domain form posts. So a nefarious site could have users post under their credentials to your API.

jonkri commented 9 years ago

Ah, thanks for the clarification around using --data-binary, and for the cross domain form post warning! :) The binary upload will work for me for now.

I don't know whether or not form posts is a good feature for this library...

hesselink commented 9 years ago

We've wanted something like it for a while, since otherwise you cannot post e.g. a file and its name together, but you have to do it in two separate calls.

Good to know you have it working!

bergmark commented 9 years ago

If we check the referrer + the user's browser isn't vulnerable to spoofing the referrer, it should be safe right?

hesselink commented 9 years ago

The problem with referrer checking is that often you get no referrer.

jonkri commented 9 years ago

Ah, yes - it would indeed be good to be able to include other information along with the data. :)

jonkri commented 8 years ago

Hi again, everyone!

I'm now reaching a point where it looks like I will need to somehow get a file delivered using the multipart/form-data encoding. Has there been any progress on this?

Cheers!

hesselink commented 8 years ago

No, we haven't worked on this at all. If you want to work on this, it would probably be best to discuss your needs and the design here, I think.