incomplete file downloads


I’m banging my head over a problem and I’m sure I’m missing something. Your external eyes are appreciated :slight_smile:

I’m making a web server that will act as a web service (REST). I’m using a web standalone app and handle all incoming requests using the HandleURL event. I have several requests that work just fine, including requests to open a session which I track manually, getting data, etc. I’m working on secure connections and the certificate works fine.

The problem I see is when the client tries to download files larger than about 2.7 megs. If I download the file over s non-secure connection, all’s good. If I switch to a secure connection, any file larger than this size are incompletely downloaded. I thought it could be the client (which I wrote too) but then I tested the url straight in Safari, with the same result.

Here’s the code that handles the “test” url I made for testing in the app.HandleURL event:

if request.path="test" then

  'get a test jpeg file located beside the web app
  dim f as FolderItem = GetFolderItem("test.jpg")
  'I set the mime type to octet stream as the real data I download is a binary file, but Safari handles it correctly anyways
  request.MIMEType = "application/octet-stream"
  request.Status = 200
  'pass the file to the request
  request.File = f
  'tell Xojo we handled the request
  return true

 end if

As you can see, it’s pretty basic (to me anyways).

To test, in Safari, I type

Other observations:
-in Safari, if I enable “Show Web Inspector” (in the developer version of Safari), then it works even in secure mode
-if I first access the regular web page which I use as an admin console, and then I type in the address bar the url to access the test file, it works even in secure mode.

Also, instead of passing the folder item, I tried opening the file as a binary stream manually and using the request.print method to print the entire content of the file. Same result.

System: OSX Yosemite
Xojo 2015R1 (pro user)
Command-line arguments: --secureport=8443

The behaviour is present both in debug and compiled app. I also tried the compiled app on the actual server that will be hosting it (A recent Mac Mini).

Again, all other urls work fine both in http and https. Only larger files in https exhibit this problem. Is there a header I need to set? Something else I’m overlooking?



I’ve setup a simple server. Take a look at this simple server that I set up, including a link to download the project.

It looks like a kind of timeout problem with the https connection - the connection simply drops before the file is completely downloaded. The problem is even worse over the internet vs a local connection. And, it only happens over https.

Again, help would be appreciated.


Have you tried to open the incomplete file in a text editor ? Very often, it contains valuable information about the error.

It looks like your file may have gone out of scope. It is possible that https being somewhat smaller, the handleURL event terminates before you had time to download the entirety of the file.

Why not create a webfile property in App that you know will not go out of scope, initialize it with your file, and pass that instead ? You may have better luck.

Hi Michel and thanks for your answer.

I opened the incomplete Safari .download file (which I learned is a directory) and I see a plist and a partial jpg. So it is really an incompleted download. I also tried with curl and it gives me and error saying that the connection was closed with xxx bytes left to receive.

I looked at the webfile, but I’m not using web sessions, just handleurl, and the webfile does not seem to be able to send the file over a secure connection. It gives a url that does work, but over an insecure connection. I’d like the file transfer to take place over an https connection.

Also, instead of passing the folderitem to the request (request.File = f) I tried to open the file in a binary stream and using request.print to read and pass the entire data, then close the file, and return. I get the same error.

And… it works fine in http.

A webfile is an object that has no need for a session. I have used Refresh to trigger a download from a webfile in the handleURL event this way.

  • Add a MyFile Webfile property to App
  • Here is the code I used :

Function HandleURL(Request As WebRequest) As Boolean app.myfile = new webfile Dim f As FolderItem = specialfolder.desktop.child("blue.jpeg") If f <> Nil And f.Exists Then App.MyFile = WebFile.Open(f) // MyFile is a property on the App object App.MyFile.ForceDownload = True End If request.print "<HTML><HEAD><META HTTP-EQUIV=""REFRESH"" CONTENT=""0;URL="+""+app.myfile.URL+chr(34)+"></head> <body></body></html>" return true End Function

Since all it does is to expose a path, it should work with https as well. I am sure when Greg passes by he will be able to assist better, though.

Just to be clear, the ability to use a WebFile without a Session only happened in one of the last few releases, so make sure you’re using something new.

That said, I’m pretty sure that it will provide secure URLs as long as the app thinks it’s running securely. I’m not aware of any bug reports for downloading large files under HTTPS though.

A bug report with a sample project and a sample jpg would be handy though.

@Michel Bujardet
your method works. I can build an https full path with the url returned by the webfile. I’ll use this to complete my project. Thanks a lot.

However, it does not explain why passing a folderitem to request.file works over http but not over https. I don’t think it’s the object going out of scope. I tested this by having a global app property pointing to the folderitem, just to be sure it would always exist. I end up with the same problem.

@Greg O’Lone
I’m using the most recent release and WebFile does work, thanks for pointing this out. Note that I do use HTTPSecureSocket in other projects and it works fine. I’m only seeing this behaviour using handleurl on a secure connection and passing a folderitem to the request.file property. I’ll file a bug report with the sample project.

I opened case #38844