Cannot submit form with Adobe Reader 7

[#1]

I have created a fillable form in Adobe Acrobat 8 Professional and have enabled user user rights so that people using reader can save a copy of the PDF.



On the form itself, there is a button that is of type submit that specifies a valid URL and submits the data as XDP.



Whilst working in Lifecycle Designer or Adobe Professional, I am able to submit the form and its content. Once I open the PDF in Adobe Reader 7.0, when I try to submit the form I always get this error "cannot handle content type text/html; charset=utf-8".



I have no idea what is the error and I am hoping some one can provide some guidance.



Thanks

[#2]

This doesn't sound like a problem with the submission, but with the

response from the web script. Is the script actually receiving the

data? Does it indeed return text/html?



Aandi Inston

[#3]

I dont think it is a problem with the web form as it works perfectly fine if I was to open the PDF in Adobe 8 Professional and submit it there.



The problem only occurs when I open it in Adobe Reader 7 and try to submit it.

[#4]

>I dont think it is a problem with the web form as it works perfectly fine if I was to open the PDF in Adobe 8 Professional and submit it there.



Well, Acrobat Professional can process an HTML format reply.

>

>The problem only occurs when I open it in Adobe Reader 7 and try to submit it.



This sounds consistent.



You didn't answer my two questions: Is the script actually receiving

the data? Does it indeed return text/html?





Aandi Inston

[#5]

Hi Aandi,



The script is an ASP.NET web page and I have managed to get it to receive the XDP package which contains the PDF encoded in base64 and the XML data.



So now the READER can post the data back and the web server can parse the XDP and save the contents but it still gets the content type error.



What must I set on the server to prevent this error from appearing.

I have already cleared the HTTP response so that it returns nothing. Should I also be setting a content type on the response so that Reader can handle it gracefully.

[#6]

>What must I set on the server to prevent this error from appearing.



>I have already cleared the HTTP response so that it returns nothing. Should I also be setting a content type on the response so that Reader can handle it gracefully.



A response must have a content-type. There may be a default being

applied, but without one the response would be just invalid. Many

content-types would consider an empty response to be an error too.



I haven't written a script in this situation, but maybe returning a

response PDF, with suitable content-type, is the answer. What are

others doing?



Aandi Inston

[#7]

We are facing the same problem too. When users submit a PDF form by HTTP Post, the server sends a html answer back - but the Adobe Reader "cannot handle content-type: html". The problem seems to exist for years already. I found several forum and blog entries - but no solution so far. Adobe seems to ignore the problem...

[#8]

It is certainly true that Adobe Reader can't handle text/html - it

isn't a web browser and doesn't have HTML function - so what other

content types have you tried? (I think some versions may give the

error and others may fail silently). I don't think Adobe are ignoring

the problem: the message is clear and Reader is working as designed. I

imagine to work you need to return a suitable PDF or XML response.



I agree it would be very helpful if Adobe provided accessible

information on what they do expect. This may be a reflection of their

wish to sell LiveCycle server products to handle your submission.



Anyone out there with a working solution?



Aandi Inston

[#9]

Hi Aandi. Thanks for answering. You were right: our server is now sendig back the answer as PDF and it works.



best regards

Sandro Looser

[#10]

We had the same problem and now return a pdf document as the response to the submit button.



The confirmation pdf is returned to the reader which then shown it in another window.



We had intended to return the user to a page on the server, but that was not working the way we expected.