mattstevens
File upload
RoutingHTTPServer seems quite promising and it has already helped me alot. Thanks for sharing it.
Question: How do i upload file using RoutingHTTPServer. can you please include an example for it.
I've added a very basic sample, in your route you can access the body data through [request body]. If you're using an HTML form to upload the file you'll need to parse the form data yourself today. There's also no handling of large uploads yet; the entire file goes into memory.
wow great...looking into it right now. I have to upload large files, so I might have to play around with it a bit. I am trying to replace the original buggy server in PlayerXtreme.
BTW, I am beginning to love RoutingHTTPServer, the simplified routing and blocks has made life easy for me.
Does the upload use chunks so that the iPad won't kill the process if too much RAM is used for a large document?
Ooops -- just read your earlier post --- no handling of large uploads --- is that coming soon?
Given how simple it is to create routing, it would be great if the library also had a nice high level abstraction to get uploaded files without the need for user to parse the data directly. (just my two cents)
Uploads aren't something I've needed myself yet but there have been a number of requests for it, if I get some time I'll look into adding it.
When you say 'uploads', are you saying support a chunked POST to the server that efficiently writes the POSTed data to a file and avoids keeping the entire POST data in memory?
If that is the goal, then I am also interested in that!!!
Charlie
On Nov 24, 2012, at 11:15 AM, Matt Stevens wrote:
Uploads aren't something I've needed myself yet but there have been a number of requests for it, if I get some time I'll look into adding it.
— Reply to this email directly or view it on GitHub.
I've been looking at this --- I will have to do a quick hack to get something that will work in the short term but ideally, along with the dictionary of headers that become available when one responds to a POST request, there could be an array of "Boundary" items, where each entry would be a dictionary with the parameters that come back in a boundary (e.g, the content type, disposition, filename etc) and an NSData blob representing the actual uploaded file. That way, the user of the library could simply iterate the array, look at the type of the content and then just process each blob as appropriate. Probably easier to start with a non-chunked version and then do the chunking later.
That seems very much the opposite of whatI was looking for. I am looking for something that does NOT keep all the posted data in memory.
On Nov 24, 2012, at 12:01 PM, dhjdhj wrote:
I've been looking at this --- I will have to do a quick hack to get something that will work in the short term but ideally, along with the dictionary of headers that become available when one responds to a POST request, there could be an array of "Boundary" items, where each entry would be a dictionary with the parameters that come back in a boundary (e.g, the content type, disposition, filename etc) and an NSData blob representing the actual uploaded file. That way, the user of the library could simply iterate the array, look at the type of the content and then just process each blob as appropriate.
— Reply to this email directly or view it on GitHub.
I understand --- I think both are needed, it depends on what's being posted and why.
For your example, the array that came back would have filenames rather than the actual blobs and the developer could then reload (or move) the data as needed.
Yes, that would be sweet!
On Nov 24, 2012, at 12:09 PM, dhjdhj wrote:
I understand --- I think both are needed, it depends on what's being posted and why.
For your example, the array that came back would have filenames rather than the actual blobs and the developer could then reload (or move) the data as needed.
— Reply to this email directly or view it on GitHub.