HTTP Submit
There are a number of different ways to submit a form, and which one is right depends on context. When your form is part of a workflow created with Adobe's Workflow Server, you need to submit using the LiveCycle Workflow fields:
These ensure that the user has the controls they need for the state they're at in the workflow.
Outside of Workflow, you can still create forms that integrate with server side processes. Form Designer and Reader support two methods for submitting data: submitting form data as application/x-www-form-urlencoded using HTTP POST, and SOAP. The former is what I'm talking about in this post.
When you create an HTML form, you add some HTML fields, and a URL to POST to as the <form> tag's action. For example:
<form method="post" action="http://stevex.net/dump.php"> <label>TextField1 <input type="text" name="TextField1" /> </label>
</form>
I've created a simple PHP script that dumps out what you submit to it parsed (so you can see what variables PHP found in the submitted data) as well as the raw POST body. The script is here. Typing "hello" into the text field and submitting this form shows that the following data was sent to the action URL:
TextField1=hello
Simple enough. It gets more complicated when there are more fields or special characters need escaping; the exact details of how that works are spelled out in the HTML 4.01 spec section 17.13.4 which covers application/x-www-form-urlencoded encoding, the MIME type that form data is submitted with.
So that's how HTML submit works. What happens when you create a form with Form Designer and want to submit it using HTTP?
Here's how to create a form equivalent to that little HTML form described above.
- Create a new form.
- Add some fields.
- Drop an HTTP Submit Button from the Library.
- Configure the HTTP Submit Button.
After step 3, you'll have a Submit button on the form, with a wee yellow marker. Hover the mouse over the marker and you'll see this message:
This handy reminder just lets you know that you need to click on the Submit button and in the Object Inspector, set the URL that the form will be posted to to something. (I don't know about you but when creating HTML forms I've forgotten to enter the action URL more than once).
Designer's preview is actually an embedded Internet Exporer, with a temporary PDF rendering of your form loaded into it. This means clicking the Submit button in the preview window will submit your form and you can see the results of the submit right in Designer.
Submitting from Acrobat is a bit more involved because Acrobat can't display the HTML response directoy, but what happens is actually pretty cool. The HTTP submit happens, and the resulting HTML is captured by Acrobat and converted into a PDF, so you see the dump response page, but you see it in Acrobat as a PDF.
There are some limitations that come with submitting form data as HTTP. Because HTML forms aren't hierarchial, any hierarchy in your own form is lost - for example, nesting fields within subforms will cause them to not appear in the submitted data. These limitations are mentioned in Designer's documentation.
I've attached my sample HTTP Submit PDF form so you can have a look at a few different field types and how they look in the submitted data.
So that covers HTTP submit. You can do a lot more with SOAP than just submit data, but that's another story.
Comments
Hi Steve, thanks for posting this -- I'm a total LiveCycle newbie, and it's been a little frustrating.
I have been having no luck using HTTP posting, so I tried to take a look at your sample PDF and get the error "Invalid enumerated value: urlencoded". Then when I submit it to dump.php no data is displayed. Any ideas?
Posted by: prescott | May 10, 2006 11:26 AM
Wow, great info, thank you for taking the time to put this together screen shots and all. Any chance of seeing the php script you used server-side? You seem to be catching more post data than I am able to using a similar form I created. Thanks again!
Posted by: Craig Cassidy | May 10, 2006 08:10 PM
prescott, are you using a Mac or a PC? I noticed on the Mac I get a similar error; I'm trying to figure out what that is.
Craig - to get the extra headers I had to us some code I found elsewhere that enumerates the $_SERVER collection filtering for variables whose names start with HTTP_ and uses that as the collection of headers. Google for emu_getallheaders and you'll find it.
For some reason the Content-Type doesn't show up in the $_SERVER collection as HTTP_CONTENT_TYPE, it shows up simply as CONTENT_TYPE, so I added an extra line to that function:
$headers["CONTENT_TYPE"]=$_SERVER["CONTENT_TYPE"];
Posted by: Steve Tibbett | May 11, 2006 07:45 AM
Thanks for the response! What about the post data? When I submit your pdf to a php script that does a var_dump() on $_POST all I get is:
array(0) { }
Posted by: Craig Cassidy | May 11, 2006 05:03 PM
The plot thickens, I guess, since I'm using Windows... I finally gave up on this particular project since I was under deadline and wound up redoing the form in Acrobat 5.0 on an old laptop, lol.
There seems to be a steep learning curve for Designer, for me anyways...
Posted by: prescott | May 11, 2006 10:18 PM
hello I´m a student(spain) and i need information to doing submit from pdf to php.
Can you help me please?
thanks
Posted by: diego | May 16, 2006 07:07 AM
Hod do I access dump.php to review your code?
Posted by: conch | May 20, 2006 12:54 PM
Hod do I access dump.php to review your code?
Posted by: conch | May 20, 2006 12:54 PM
You can view the PHP source at http://stevex.net/dump.txt.
Posted by: Steve Tibbett | May 21, 2006 08:59 AM
Hi Steve.
Thanks for the great info on HTTP submits. Inspired by your blog entry I've tried to make a questionaire that submits the data to a php script which then is supposed to process the data. I can't seem to create a similar php script that catches the same amount of information as yours and the link to the source you've posted don't seem to contain the correct data - would it be possible to get this corrected?
Thanks in advance
Christian Rasmussen, Denmark
Posted by: Christian Rasmussen | June 1, 2006 04:05 AM
Make sure you're using the HTTP Submit button, not the Submit button.. or if you use the Submit button, have the encoding set to URL-encoded.. otherwise PHP won't automatically parse the fields out for you.
Posted by: stevex | June 1, 2006 06:45 AM
Steve, I looked at your form in Designer and see that the URL-encoded button actually sends XML Data Package data. When I changed it to URL-encoded and saved it, the php dump no longer worked: for data, it gave me this: "form1: Array". Is that correct, or am I just crazy?
Thanks,
Chris
Posted by: chris | June 5, 2006 07:42 PM
I found this info from http://www.ammug.org/drupal/node/101
"Highlight the submit button and click the XML Source tab. Below the tag, near the tag for the button, find and change format="formdata" to format="urlencoded" "
Suddenly, my http submit button works. Could this be a version bug? I'm using v. 7, 0, 041126, 0. Seems like I shouldn't have to change the XML to get the button to send data correctly. In any case, thanks for a very informative blog, Steve!
Chris.
Posted by: Chris | June 6, 2006 05:22 PM
How did you create the button? I'm curious how you got the "formdata" format in the first place.
Posted by: stevex | June 8, 2006 07:54 AM
Hello Steve,
I'm writing an application which receives an http submit from an xfa based PDF.
I'm successful in getting the XDP XML from the request object. However, what I really need is the XML formatted as configured via the data binding in Adobe designer.
During development of the form I used the email submit to inspect the resulting XML. This was working perfectly.
Is there a way to get the XML from an HTTP submit in the same format as the email submit?
Cheers!
Dylan Doxey
UCSD / eForms
Posted by: Dylan Doxey | September 3, 2006 12:21 PM
Hello Steve,
Regarding my preceding comment. I answered my own question by examining your SubmitComparisons.pdf.
I changed the submit button attribute format="urlencoded" to format="xml" and now I'm getting exactly what I wanted.
Thanks!
Dylan Doxey
UCSD / eForms
Posted by: Dylan Doxey | September 3, 2006 12:48 PM
From the rfc link:
application/x-www-form-urlencoded
This is the default content type. Forms submitted with this content type must be encoded as follows:
1. Control names and values are escaped. Space characters are replaced by `+', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A').
2. The control names/values are listed in the order they appear in the document. The name is separated from the value by `=' and name/value pairs are separated from each other by `&'.
I see no ampersands (&) seperating the name value pairs. This occurs on your test form as well. Exmaple output from dump.php:
Submitted Variables (as parsed by PHP)
TextField1: 1TextField2=2RichTextField=ListBox1=Third ItemRadioButtonList=3
Raw POST Body
83 bytes:
TextField1=1TextField2=2RichTextField=%3cz%3eListBox1=Third%
20ItemRadioButtonList=3
Why does Acrobat not follow the form standard and seperate the name/value pairs with ampersands? Am I missing something here?
Posted by: Jacob Heidt | September 25, 2007 02:05 PM