0

I am developing an application that, in a nutshell, handles a PDF form. The submission data format is XFDF. So far, so good, but I'm getting some very strange behavior from the clients.

The PDF viewer is Adobe Reader (currently 11.0.6) in IE. This is an internal application, so there is no need to support anything else right now. The PDF is created dynamically on the server, so I have to do this in the browser rather than the standalone application.

The workflow is this:

  1. An e-mail message is sent to the user, containing a link to a URL inside the application.
  2. The user clicks the link. The browser opens and requests the specified URL.
  3. The application delivers a PDF file (content type application/pdf).
  4. The user completes a form inside the PDF.
  5. The user clicks the "submit" button in the form.
  6. The PDF viewer and browser somehow cooperate to POST the form data back to the server, to a slightly different URL than that of the form itself (the form URL ends with a slash, and the submit action's URL is "submit/", therefore, it is appended).
  7. The application processes the data and returns a 303 redirect to a status page. (The problem occurs just the same if I send a 302 instead.)
  8. The browser GETs the status page (and any referenced resources).

What actually happens in step 8 is this: The browser requests the status page, but when it gets to the CSS stylesheet referenced in the page, it sends this:

GET /static/app.css HTTP/1.1
Accept: text/css, */*
Acrobat-Version: 11.0.6
Accept-Language: en-GB
Content-Type: application/vnd.adobe.xfdf; charset=utf-8
Content-Length: 1824
Referer: http://application/report/2014-03-28/925/
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: application
DNT: 1
Connection: Keep-Alive
Cookie: sessionid=12345

Note that this request contains both a Content-Type and Content-Length header, which is unusual enough for a GET request, but there is no request body, not one byte, not 1824 of them. My server is IIS, which responds to this request with a 400 Invalid Verb (not sure why that particular error, but the 400 as such is certainly justified).

The request for the status page itself does not contain these headers; it is perfectly correct. For some reason, the stylesheet request repeats the headers from the form submission two requests earlier.

There is unfortunately not a lot of documentation for sending PDF form data via HTTP, but as far as I know, I'm doing everything right. I assume this is a bug in the Adobe Reader plugin and/or IE; can anyone think of a way to work around it?

Christian
  • 71
  • 1
  • 5

2 Answers2

0

There are a few things to keep in mind when submitting forms data.

a) how does your submit command look like?

According to the Acrobat JavaScript documentation, the URL to submit to must end with #FDF if you submit as FDF or XFDF. That will make sure that the (X)FDF is transmitted. If that add-on is omitted, Acrobat/Reader may submit as HTML POST.

b) the answer should be fine as long as you are running Acrobat/Reader under a webbrowser. Otherwise, Reader does not understand the return codes from the server; instead you should return either a PDF or an FDF.

It may be helpful to get the FDFToolkit from the Adobe website. Even if you decide to not use it, the documentation has decent explanations on how things do work.

Max Wyss
  • 3,549
  • 2
  • 20
  • 26
  • My submit command is the default PDF form button, with an action of "Submit form" set to send fields only as XFDF. The URL does not end with #FDF because that is _only_ for submitting as FDF, not XFDF. I tried it initially with #FDF, but that failed in a different way (the submit was repeated immediately, and the redirection not followed). There was also a previous version of this code that did not return an HTTP redirection, but instead an XFDF document that set a status field in the form itself, instead of returning to the status page. That worked adequately, but always required two tabs. – Christian Apr 04 '14 at 14:53
0

I recently encountered this exact issue. I am submitting a PDF as XFDF via embedded button. I successfully persist the data, and then return an HTML response. Through fiddler I can see that the response is well-formed and successful (status code 200).

As the browser renders the response it makes additional requests for the referenced CSS/JS files (as usual). These requests have a contentType of "application/vnd.adobe.xfdf" and a contentLength, which clearly doesn't make sense for the content being requested.

I was not able to find a solid fix for this, but did come up with a decent workaround for my purposes. I suspect these requests are still being made somehow within the context of Acrobat Reader, so my thinking was to return an initial response devoid of any CSS/JS to satisfy Acrobat and return control entirely to the browser. Instead of returning a redirect header or complex content, I simply return this:

<html>
<head>
<meta HTTP-EQUIV="REFRESH" content="0;url=http://example.com/myapp/mypage.html">
</head>
<body>
<h3>Submission successful, returning to XYZ</h3>
</body>
</html>

Sure enough, the subsequent redirect is successful and all JS/CSS requests are well-formed. The only drawback is the user briefly sees this empty page during redirection, but I can live with that in my project...

RevBB
  • 11
  • 1