2014-04-03 2 views
0

간단히 말해서 PDF 양식을 처리하는 응용 프로그램을 개발 중입니다. 제출 데이터 형식은 XFDF입니다. 지금까지는 그렇게 좋았지 만 클라이언트로부터 아주 이상한 행동을하고 있습니다.HTTP를 통해 PDF 양식 데이터를 제출하는 방법은 무엇입니까?

PDF 뷰어는 IE의 Adobe Reader (현재 11.0.6)입니다. 이것은 내부 애플리케이션이므로 지금 당장은 다른 것을 지원할 필요가 없습니다. PDF는 서버에서 동적으로 생성되므로 독립 실행 형 응용 프로그램이 아닌 브라우저에서이 작업을 수행해야합니다.

워크 플로는 이것이다 :

  1. 전자 메일 메시지는 응용 프로그램 내부의 URL에 대한 링크를 포함하는, 사용자에게 전송됩니다.
  2. 사용자가 링크를 클릭합니다. 브라우저가 열리고 지정된 URL을 요청합니다.
  3. 응용 프로그램은 PDF 파일 (콘텐츠 유형 application/pdf)을 제공합니다.
  4. 사용자가 PDF 내에서 양식을 완성합니다.
  5. 사용자가 양식의 "제출"버튼을 클릭합니다.
  6. PDF 뷰어와 브라우저는 어떻게 든 폼 데이터를 POST와 협력하여 양식 자체와 URL이 약간 다른 (양식 URL은 슬래시로 끝나고 제출 작업 URL은 "submit"입니다./"이므로 추가됩니다).
  7. 응용 프로그램에서 데이터를 처리하고 상태 페이지로 303 리디렉션을 반환합니다. ( 은 302를 보내면 똑같이 발생합니다.)
  8. 브라우저가 상태 페이지 (및 참조 된 모든 리소스)를 얻습니다.

무엇 실제로 8 단계에서 발생하는 것은 이것이다 : 브라우저가 상태 페이지를 요청하지만 페이지에서 참조하는 CSS 스타일 시트에 도달 할 때, 그것은이 전송 :

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 

주 그 요청 Content-Type 및 Content-Length 헤더가 모두 포함되어 있습니다. GET 요청에 대해 매우 특이한 내용이지만, 요청 본문이 아니고 1 바이트가 아니라 1824 개입니다. 내 서버는 IIS입니다.이 요청에 대해 400 개의 잘못된 동사가 응답합니다 (특정 오류는 아닌 이유는 확실하지만 400은 확실하게 정당화됩니다).

상태 페이지 자체에 대한 요청이 이 아니고에 이러한 헤더가 포함되어 있습니다. 그것은 완벽하게 정확합니다. 어떤 이유로 스타일 시트 요청은 양식 제출 두 개의 요청에서 헤더를 더 일찍 반복합니다.

불행히도 HTTP를 통해 PDF 양식 데이터를 전송하는 데 필요한 문서가 많지 않지만, 제가 아는 한 모든 것을 올바르게하고 있습니다. 이 버그는 Adobe Reader 플러그인 및/또는 IE의 버그라고 가정합니다. 누구든지 그것을 해결할 방법을 생각할 수 있습니까?

답변

0

양식 데이터를 제출할 때 유의해야 할 몇 가지 사항이 있습니다.

a) 제출 명령은 어떻게 생겼습니까?

Acrobat JavaScript 설명서에 따르면 제출할 URL은 FDF 또는 XFDF로 제출하는 경우 #FDF로 끝나야합니다. 그러면 (X) FDF가 전송됩니다. 해당 부가 기능이 생략되면 Acrobat/Reader가 HTML POST로 제출할 수 있습니다.

b) 웹 브라우저에서 Acrobat/Reader를 실행하고있는 한 대답은 괜찮습니다. 그렇지 않으면, Reader는 서버의 리턴 코드를 인식하지 못합니다. PDF 또는 FDF를 반환해야합니다.

Adobe 웹 사이트에서 FDFToolkit을 구하는 것이 도움이 될 수 있습니다. 비록 당신이 그것을 사용하지 않기로 결정하더라도, 문서는 일들이 어떻게 작동하는지에 대한 훌륭한 설명을 가지고 있습니다.

+0

내 제출 명령은 "양식 제출"작업이있는 기본 PDF 양식 버튼입니다. 필드는 XFDF로만 사용됩니다. URL은 #FDF로 끝나지 않습니다. 그 이유는 XFDF가 아닌 FDF로 제출하기 위해 _only_이기 때문입니다. #FDF로 처음 시도했지만 다른 방식으로 실패했습니다 (제출이 즉시 반복되었고 리디렉션이 따르지 않음). 또한 HTTP 리디렉션을 반환하지 않는이 코드의 이전 버전이 있었지만 상태 페이지로 돌아가는 대신 양식 자체에 상태 필드를 설정하는 XFDF 문서가있었습니다. 그것은 제대로 작동했지만 항상 두 개의 탭이 필요했습니다. – Christian

0

최근이 정확한 문제가 발생했습니다. PDF를 XFDF로 포함 버튼을 통해 제출하고 있습니다. 성공적으로 데이터를 유지 한 다음 HTML 응답을 반환합니다. 피 들러를 통해 나는 응답이 잘 형성되고 성공적이라는 것을 알 수있다 (상태 코드 200).

브라우저가 응답을 렌더링 할 때 참조 된 CSS/JS 파일에 대해 추가 요청을합니다 (평소와 같이). 이러한 요청에는 contentType이 "application/vnd.adobe.xfdf"이고 contentLength가 있습니다. 이는 콘텐츠가 요청 된 것이 분명하지 않습니다.

솔리드 픽스를 찾을 수 없었지만 제 목적에 맞는 적절한 해결책을 찾지 못했습니다. 필자는 이러한 요청이 여전히 Acrobat Reader의 컨텍스트 내에서 어떻게 든 만들어 졌다고 생각합니다. 따라서 생각해 보면 Acrobat/Acrobat을 만족시키고 브라우저에 컨트롤을 완전히 되돌리기위한 CSS/JS가없는 초기 응답을 반환하는 것이 좋습니다. 대신 리디렉션 헤더 또는 복잡한 내용을 반환하는, 단순히 반환이 :

<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> 

아니나 다를까, 이후 리디렉션이 성공하고 모든 JS/CSS 요청은 잘 형성된다. 유일한 단점은 사용자가 잠시 리다이렉션 중에이 빈 페이지를 보지만 내 프로젝트에서 그 빈 페이지를 볼 수 있다는 것입니다 ...

관련 문제