Requesting a file from a server to memory

Targets Web
1

I need to get a file asynchronously using URLConnection and transfer it to an EmailAttachment. The web service has no disk access. How is this done?

2

A Web App can access its own drive, so where is the file stored?
You may need to upload/download the file first (via FTP, CURL, etc), then the Web App will know where it stored the file. Alternatively, send the file along with the URLConnection.

3

Thanks David, but the web app is stateless and has no drive. From the docs it seems URL connection for “downloading” to the server requires an already created FolderItem which is bound to a drive? Same with EmailAttachment.

Looks to me I will have to Shell to create a ram drive in this case.

4

EmailAttachment has a Data property, but the documentation on it is unclear if you’re able to use it to create an attachment - the description only mentions receiving.

If the Data property works to create an attachment, you should be able to pull this off in memory. If you don’t provide a FolderItem to the Send request for a file you’ll get the contents as a String in ContentReceived. Pass that string to the Data property of an EmailAttachment (again assuming you can).

5

Thanks for the tip Tim but we can’t get the SecureSMTP working at all on my rig. It fails silently in Web2 2021r1.1 but we are checking it out in another Dev environment as a sanity check.

6

Thanks Tim, tried it but the images inside the PDF didn’t render correctly with content string set to ASCII or UDF8. Is there a standard around this? (UDF8 is required for the pdf’s text.)

7

This issue still occurs when I put the content data (with encoding set to nil) into a memory block and pass it around Xojo that way. Also, the resulting PDF renders text (but not pixmaps) in the browser but an empty frame structure with no text in a standalone PDF reader. The original linked document does not do that so the problem appears either in conversion to a string in content received event or from memory block into EmailAttchment.Data which is also a string.

My theory is Xojo strings “do stuff” to change raw data - maybe that’s why JsonItem encoding is such a pain, because JSON could be binary data which <> string in Xojo?

8

On the other hand, or maybe as well, when content received event gets the content as string, it’s still encoded per the mime type? Then we put it in the EmailAttachment.data and it gets encoded again? How do we decode the data after getting the filedata in the content received event for Xojo to pass the file data internally without disk?

9

No mime type setting shouldn’t change the data on transfer. I think this is a data>Xojo.string>data thing.