*Background:*I have a "document repository" kind-of app.The iOS app calls a WCF service to download the document as well as to get its metadata(document name,document size,etc).There is also a .Net client used for uploading the documents.When I upload a document,I save it in the "AppDomain.CurrentDomain.BaseDirectory" by creating a separate folder for each document.So,effectively,the document is stored at "C:\inetpub\wwwroot\Foo\bar\document.doc".
*The Problem:*when the iOS app tries to download a document,it returns error 500 "Could not find a part of the path 'C:\inetpub\wwwroot\Foo\bar\document.doc'" However,it returns the metadata for the document(document name,document size,document location,etc.) correctly.
What should I do the make the app download the document?
The error 500 was sending back from the server. So the problem is on server side. Are you sure that the path is correct? The uploaded document is on that directory?
Related
We have a React PWA where we initially download RTF-Documents and save them to an indexDB. We use createObjectURL and an a with a.click() to simulate a download when the file is requested by the User.
The mimetype is set to application/rtf in the createObjectURL call.
However, on iOS (with Safari) the default "view" operation shows the following:
This file cannot be previewed
It might be corrupted or of an unknown file format.
The same file works from our "normal" webapp (i.e. file is served from a backend server). I tried to set the headers exactly like our backend server does, but it either doesn't show the "view" Button at all or it shows the error.
Any ideas how to set up the calls, so iOS will show the RTF correctly?
this is kinda tricky.. let's make this clearer :
I'm using a ruby on rails app as back-end for my mobile application, when i upload a video from my ruby app Dashboard and store it on AWS S3 Storage it works perfectly, and when i retrieve the URL for the video it works as well , the thing when i click it it automatically download the video instead of playing it, i checked the meta data of the object inside my AWS Console it has the ( System defined Content-Type video/mp4 ) but as the attached screenshot show it doesn't recognize it as a video (as type is - as of null )
my response is always as JSON since i use the ruby app for the web services and the dashboard only ( i get the correct response )
PS: the video uploaded manually from the AWS Console plays when u open the link.
this is the difference between the video uploaded using my ruby app and the video uploaded manually which is highlighted in red
Look into how to set S3 Content Disposition with the library you're using. You'll need to probably do this when you're uploading the file, or you might be able to coerce it at request time when generating the link to the asset.
History:
I am working on a project for which we need to support:
Background Upload of files using NSURLSession.
The server expects file to be uploaded using Content-Type: multipart/form-data
Previously, I was using NSURLConnection with bound pair of Streams as depicted in this Apple Sample.
Now, I wish to follow similar approach with NSURLSession(Background Session) by using uploadTaskWithStreamedRequest:.
I have written a small stand-alone iOS Sample + a PHP server to validate my concept.
Problem: Everything works if app stays in foreground, but if during upload I press the home key, the upload fails after some time with error:
Domain=NSURLErrorDomain Code=-997 "Lost connection to background transfer service"
Also a little before the upload fails the Write/Producer Stream's NSStreamEventEndEncountered is encountered.
Note: I know the work-around where I can write whole HTTP Post body to a temp file and use NSURLSession's file upload API instead. But above is more appropriate if I can make it work.
Question: Can anyone guess what could be possible reason for the upload getting failed?
Sample Code: I have uploaded the iOS Sample Code + PHP Server Code to drop box. Here is the CODE
Thanks!
You can't upload streamed tasks using Background Configuration. I successfully upload data only in two cases:
Download task with data stored in request body.
Upload task from file. In that case you will not receive response body.
I have created on web app which supports html5 appcache and I can load that app offline.
I can also see that appcache when I visit URL chrome://appcache-internals/
Now I am using same offline weburl to work on cefclient applicaiton (https://code.google.com/p/chromiumembedded/)
As soon as I try to load that offline url ,exisiting entry from chrome://appcache-internals/ gets removed and my offline web app is not working in cef.
any idea why that is happening. How can I find out why appcache not working with cef.
Is there any difference between creating a direct link to a file on a server, and doing something like reading the file from a location and setting the content type header then streaming back the data.
I'm curious because I have a webserver that i'm using to download apps to a blackberry, if i create a file and have a direct link to that file it works, but if i stream it back using an webpage it doesn't work. The phone gets the file but it doesn't work.
Things to note:
urls are the same in both cases ie (http://somesite.com/download/file.jad)
in a browser using fiddler the downloads/header are exactly the same byte for byte
So why would the phone prefer a file that's actually a direct link vs one that is a controller streaming the data back when the data transmitted and the url are identical?
The .JAD file is just the first part of the download - there are also the .COD files associated with it (referenced in the JAD). Did you ensure that your "streaming" method is sending back the COD file correctly and with the correct MIME types?
I discovered a fix for this problem though I'm still not sure what causes it. I have been delivering the link to the phone through the sms/email gateway. When the phone gets the sms and I select the link for download it asks if i want to get the jad i hit yes and it shows up and drop out. I put the exact same link on another page as an html link and sent an sms pointing to that page. The web site throws an error... So I copied and pasted the link into the phones browser and the page shows up just fine, I click the jad download link on the page and now the jad works fine.
So i'm thinking two things either there is some sort of security mechanism that prevents direct links in sms(but this has worked for other files) Or the way the phone gets the url is different.
I ran some tests and noticed something else, on a page that accepts an id value (http://site.com/download/145) where 145 is an id for a file, if you go to that link in a phone browser it works fine and you download the file. If you send it in an sms the server errors out saying that the id is expected to be a float and it received a string. So why is it that when the phone links directly from sms the url parameters are strings but when used in a browser the actually get parsed as a float?
Sorry for the long winded explanation but it's a strange issue.