Just in case anyone wants to check my work here, below is the bug report and sample code that I submitted today, which I believe proves that network.request is incapable of sending “binary” data (otherwise known as “data”). Note that I’ve also tried using network.download in all of these tests, tried various header combinations (including other c/t headers and no c/t header), and lots of other stuff.
_In attempting to upload binary files to online services via a REST interface, specifically Parse and Dropbox, they expect that the client can create a POST request where the body of said request is the binary content of the file.
The documentation for the “body” attribute of params in network.request( ) is as follows:
params.body - A string containing the HTTP body.
The documentation for the term “string” in Lua is as follows:
“Strings have the usual meaning: a sequence of characters. Lua is eight-bit clean and so strings may contain characters with any numeric value, including embedded zeros. That means that you can store any binary data into a string.”
Further, note that content/payload sent over HTTP is assumed to be binary, and that the underlying network request APIs on all Corona platforms allow for a binary request payload. In no case would this present a problem if the payload happened to be 7-bit text.
The examples below show that network.request( ) is essentially looking for a 7-bit, non-null “text” value, as opposed to processing the actual literal body provided. If a null is present in the body, network.request only processes the body up to that null. If a character with a value of greater than 127 is encountered anywhere in the body, network.request( ) transmits a zero length body.
This is not only badly broken, in that it prevents uploading of “binary” (8-bit) bodies, but also shows a profound lack of understanding of how the underlying network request mechanisms and the protocol itself work.
I would normally use the excellent LuaSocket network APIs, as I always do when I have that option, but these rest services (specifically Parse and DropBox) require an SSL connection. As there is no SSL\TLS support for LuaSocket under Corona, I have no choice but to try to use network.request. And that API is very badly broken.
Note that I am aware that there are “text based” workarounds for file uploading, specifically encoding the binary file as part of a multipart/form-data post, but that post mechanism is not supported by either of these services.
Until this is addressed, it is my opinion that it is not possible to use Parse or Dropbox, at least with binary files, from Corona.
Note: The tests are very crude, and designed to illustrate my conclusions above. I have a significant application that works with a variety of actual text and binary file, and it fails as would be expected based on these simple tests. These tests use the free httpbin auto-responding server so that you can see exactly what the server is getting from Corona._
[code]
io.output():setvbuf(‘no’)
print(“Beginning test: network.request is b0rken”)
local function fileUploadText( )
local function listener ( status )
print("fileUploadText POST response: " … status.response)
end
local params = {
headers = {
[“Content-Type”] = “text/plain”
},
body = “foo”
}
network.request(“http://httpbin.org/post”, “POST”, listener, params)
end
local function fileUploadTextWithNull( )
local function listener ( status )
print("fileUploadTextWithNull POST response: " … status.response)
end
local params = {
headers = {
[“Content-Type”] = “text/plain”
},
body = “foo\0bar”
}
network.request(“http://httpbin.org/post”, “POST”, listener, params)
end
local function fileUploadTextWithHighBit( )
local function listener ( status )
print("fileUploadTextWithHighBit POST response: " … status.response)
end
local params = {
headers = {
[“Content-Type”] = “text/plain”
},
body = “foo\128”
}
network.request(“http://httpbin.org/post”, “POST”, listener, params)
end
fileUploadText()
timer.performWithDelay(1000, fileUploadTextWithNull)
timer.performWithDelay(2000, fileUploadTextWithHighBit)
[/code] [import]uid: 111481 topic_id: 31044 reply_id: 125084[/import]
