Web Submit Confirmation Page

HTTP data submission is two way. Acrobat generates an HTTP Request and expects to see an HTTP Response. This is of course what's expected with an HTTP transaction. The issue with your server script is that it's returning HTML. Acrobat Professional automatically tries to convert the HTML into a PDF and Adobe Reader hands it off to the default browser. I believe that if you append #FDF to the submission URL that Acrobat Pro will display the returned HTML in a browser instead of trying to convert it into a PDF. But I'm not sure on this point.

A cleaner solution is to return something useful that has a benign affect on Acrobat/Reader. For example you could reflect the submitted data back, may be with some extra information embedded in it. Or send back an XDP that does not contain a dataset section. In the old days you could send an FDF back containing JavaScript code that displays an alert box. It's still possible to do this, but because of security changes its not practical.

One of the problems with sending back XDP or XML is that with a LiveCycle form Acrobat will try to use it to modify the data model. Which is why, if you are going to return data you need to return exactly what was sent. I'm not totally sure, but I think if you returned an empty XFDF that Acrobat would be do nothing an be happy. Acrobat understands XFDF so it would accept it as valid return data, but this XFDF is not compatible with LiveCycle forms so Acrobat would ignore it.

Thom Parker
The source for PDF Scripting Info
[url=http://www.pdfScripting.com]pdfscripting.com[/url]

The Acrobat JavaScript Reference, Use it Early and Often
[url=http://www.adobe.com/devnet/acrobat/javascript.php]http://www.adobe.com/devnet/acrobat/javascript.php[/url]

Then most important JavaScript Development tool in Acrobat
[url=http://www.pdfscripting.com/public/34.cfm#JSIntro][b]The Console Window (Video tutorial)[/b][/url]
[url=http://www.acrobatusers.com/tutorials/2006/javascript_console][b]The Console Window(article)[/b][/url]