- From: <vojtech.toman@emc.com>
- Date: Thu, 24 Mar 2011 09:51:52 -0400
- To: <xproc-dev@w3.org>
- Message-ID: <3799D0FD120AD940B731A37E36DAF3FE334C53B183@MX20A.corp.emc.com>
Philip, Have you tried using tcpmon (or similar) to see what the request headers and payload look like? When you are "retrieving" the PDF files from the file system using the first p:http-request, you use "text/plain" as the override-content-type. Does this actually work for you? I would expect that the c:body document that you get contains complete rubbish. The effect of using "text/plain" is that the binary PDF data will be converted to a sequence of Unicode characters. Because you don't provide character encoding information with the content type, the p:http-request will most likely interpret the bytes as "ISO-8859-1", but any other encoding will result into equally broken (or at least unusable) results, IMHO. I think the proper way would be to "retrieve" the PDF data as "application/pdf" (or any binary content type) and let p:http-request base64 encode the c:data document for you. In the second p:http-request that makes the multipart request, I would insert the base64-encoded c:body into the c:multipart element. You may need to massage the c:body attributes a bit before you insert it in the c:multipart, though. Vojtech -- Vojtech Toman Consultant Software Engineer EMC | Information Intelligence Group vojtech.toman@emc.com http://developer.emc.com/xmltech From: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] On Behalf Of Philip Fennell Sent: Wednesday, March 23, 2011 9:24 PM To: XProc Dev Subject: HTTP Post and Multipart Hello, I have a pipeline (see below) which attempts to upload PDF files from the file system to a web service using the service's API. The API requires that multipart/form-data POSTs are used. Currently I get a series of HTTP 500 status responses. As the API isn't very detailed in its responses I don't know if the problem lies in the encoding of the body or how the multipart has been constructed. I have tried sending the PDFs as content-type="text/plain" and content-type="application/octet-stream" encoding="base64" but both ways get me the same response. If I change to multipart/mixed the it complains bitterly so at least I know I haven't got that part wrong. I'm assuming that something a browser does when it sends multipart/form-data is not what's happening here. I'm doing something wrong, that's for sure, but what that is I don't know. Does anyone have any ideas? I'm using the most recent Calabash from within oXygen 12.1 on Windows 7. Regards Philip <?xml version="1.0" encoding="UTF-8"?> <p:declare-step xmlns:c=http://www.w3.org/ns/xproc-step xmlns:p="http://www.w3.org/ns/xproc" xml:base="../" name="upload" version="1.0"> <p:output port="result"/> <p:serialization port="result" encoding="UTF-8" indent="true" media-type="application/xml" method="xml"/> <p:import href="../lib/library-1.0.xpl"/> <p:directory-list name="content" path="test/resources/assets" include-filter=".*\.pdf"/> <p:make-absolute-uris name="directory" match="//c:file/@name"> <p:with-option name="base-uri" select="/c:directory/@xml:base"/> </p:make-absolute-uris> <p:for-each> <p:iteration-source select="/c:directory/c:file"/> <p:identity name="fileRef"/> <p:document-template name="get-request"> <p:input port="template"> <p:inline> <c:request method="GET" href="{/c:file/@name}" override-content-type="text/plain"/> </p:inline> </p:input> <p:input port="source"/> <p:input port="parameters"> <p:empty/> </p:input> </p:document-template> <p:http-request name="retrieve"/> <p:document-template name="post-request"> <p:input port="source"/> <p:input port="template"> <p:inline> <c:request method="POST" href="http://api.service.com/api?method=upload"> <c:multipart content-type="multipart/form-data" boundary="=-=-=-=-="> {/c:body} </c:multipart> </c:request> </p:inline> </p:input> <p:input port="parameters"> <p:empty/> </p:input> </p:document-template> <p:http-request name="create"/> </p:for-each> <p:wrap-sequence wrapper="c:result"/> </p:declare-step>
Received on Thursday, 24 March 2011 13:55:49 UTC