LiveCode Forums

I've just discovered the HTTPD Library and using the sample code in the Dictionary I can start and stop an HTTP server on iOS and Android and connect to it via a computer on the LAN. (Huzzah!)

I then created a simple HTML page that displays a form. I would like to capture any data entered via the form and use it within my LiveCode mobile app. In the old CGI days I would use an action in the form tag to call a CGI script to process the data. Something like...

<form action="process_data.cgi" method="POST" enctype="multipart/form-data">

I'm assuming I can't use an action script here so without an action script is the form data returned via POST to the LiveCode app and if so how can I access it?

Thanks for any help.
Al.

To clarify my query, here's my LC file. [This is just running on a Mac for test (you don't need to build for iOS or Android)]

Open the HTTP-Test.livecode and run it. Then using a browser go to http://<the-IP-address-show>:12345. This will display something similar to:

MacOS
192.168.1.19
Choose file to upload
[Choose File]
[Submit]
pRequest[content]=
pRequest[headers][accept]=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
pRequest[headers][accept-encoding]=gzip, deflate
pRequest[headers][accept-language]=en-gb
pRequest[headers][connection]=keep-alive
pRequest[headers][content-length]=44
pRequest[headers][content-type]=multipart/form-data; boundary=----WebKitFormBoundaryLycAxMOSgkyQXYaB
pRequest[headers][host]=192.168.1.19:12345
pRequest[headers][origin]=http://192.168.1.19:12345
pRequest[headers][referer]=http://192.168.1.19:12345/
pRequest[headers][upgrade-insecure-requests]=1
pRequest[headers][user-agent]=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.2 Safari/605.1.15
pRequest[method]=POST
pRequest[parameters]=
pRequest[port]=12345
pRequest[resource]=/

Click the Choose File button and find a .CSV file (that's what the app's looking for), then press Submit.

It appears there's no content being loaded as pRequest[content] remains empty.

However, if I add a text input field to the HTML (<input type="text" blah blah blah> ) and refresh the browser, I can type in some text and the pRequest[content] shows the text entered.

So it kinda works, but I'm trying to get a file to upload and access it.

In all probability I'm missing something obvious, but can't see it.

Anyone got any ideas?

Thnx, Al.

You cannot use html to process the formdata. You would need PHP, Perl or LivecodeServer for example. But this is not possible with the HTTPD library.

I've never looked at the httpd library, but in the Dictionary it talks about METHODS, but only specifies GET. Then the final bullet point says that for url-encoded forms the array[content] will be empty, which suggests POST is not fully implemented.

If running a httpd daemon on mobile is something you really want to do, it may well be possible to built more features into the httpd library. I'm guessing it is a minimal functionality built because that minimum was needed for a specific project. In the past I can think of a couple of people who built more full-featured httpd libraries than this appears to be.

Apart from running SSL sockets, Livecode has got socket support (as you will see if you dig into the httpd library).

Yeah I spotted the bullet points, but as I was using an enctype of multipart/form-data instead of application/x-www-form-urlencoded I thought that POST would return the data. It may actually be returning data but it's not showing, so I'm going to investigate how to decode the pRequest[content] in case there is anything in there.

Wyatt is the advantage of using an LC httpd over Apache?

The LC httpd runs on iOS and Android and I need a small server in my app.

Restricted to LAN-only?

I believe thats the case for HTTPD Library.. and I only need it to support LAN access for my app.

Hah! I think I've found the problem and why I'm getting no data returned.

In com.livecode.library.httpd there is a handler called ___ReadContinuedRequest that has some conditional logic for processing data with a "--todo" comment in the case condition for handling multipart/form-data

if sRequests[pSocketID]["content"] is empty then
set the itemDelimiter to ";"
switch item 1 of sRequests[pSocketID]["headers"]["Content-Type"]
case "application/x-www-form-urlencoded"
put __ParamsToArray(word 1 to -1 of pData) into sRequests[pSocketID]["parameters"]
break
case "multipart/form-data"
-- todo
default
put pData into sRequests[pSocketID]["content"]
end switch
end if

Open to suggestions as to how to handle the pData and format it for insertion into sRequests[pSocketID]["content"]

I'm not clear on the setup. It sounds like you have some phones on a LAN from which you'd like to send files to another phone which is always on acting as a server - is that correct?

The setup:

An iOS or Android phone connected via WiFi to the LAN.
A computer connected to the LAN
The iOS or Android phone will run an HTTP server (HTTPD Library)

The objective:

Using the computer, connect to the HTTP server running on the phone and upload a file to it.

This should be simple enough if the multipart/form-data gets processed. Currently the HTTPD Library has a "case" construct defined for multipart/form-data but the construct does not contain any code. Instead it has a comment saying "--todo".

Current situation:

I'm stuck!

This should be simple enough if the multipart/form-data gets processed. Currently the HTTPD Library has a "case" construct defined for multipart/form-data but the construct does not contain any code. Instead it has a comment saying "--todo".

If you're in control of the form, you can use JS to change to make a POST request with the values in a JSON instead, I believe that should work even though I haven't tried. You would need to change the content type to "application/json" on the request, and decode the JSON yourself on your callback handler in your stack. It should be inside pRequestA["content"], if I understood the library correctly.

LC's httpd lib handles POST?

Yes it does. Just not very well by the look of it.