- From: <Toman_Vojtech@emc.com>
- Date: Thu, 25 Feb 2010 05:16:55 -0500
- To: <public-xml-processing-model-wg@w3.org>
> Vojtech, > > I fixed some bugs in the check-multipart service and tweaked all of the > multipart tests. I now pass them all! Please let me know if you think > I broke something! Norm, It *almost* works for me :) After I made some temporary changes to my p:http-request implementation, I pass multipart-001 and multipart-002. But I still think that the check-multipart service is not 100% correct, at least in the following three cases: 1. If the very first line of the multipart body is not a boundary string, then the check-multipart service does not detect the boundary string properly. With the multipart bodies that Calumet generates, the service does not work: This is a message with multiple parts in MIME format. --aaaabbbbccccddddeeefffggghhhiiijjjkkkllmmmnop ... However, if I remove the "This is a message..." line: --aaaabbbbccccddddeeefffggghhhiiijjjkkkllmmmnop ... then the service works. But I think the check-multipart service should ignore any data before first boundary string, as MIME-compliant clients should do. 2. In the test multipart-003, one of the multipart bodies is specified as follows in c:request: <c:body content-type="text/plain; charset=iso-8859-2" encoding="base64">PHBhcmE+uWVk6SBteblpPC9wYXJhPg0K</c:body> The expected test result contains the following: <part> <header name="Content-Transfer-Encoding">base64</header> <header name="Content-Type">text/plain; charset=iso-8859-2</header> <body>PHBhcmE+uWVk6SBteblpPC9wYXJhPg0K </body> </part> However, this is not what I get with Calumet. What I get is this: <part> <header name="Content-Type">text/plain; charset=iso-8859-2</header> <body/> </part> Calumet is not sending the data base64-encoded in this case because it knows it is a text content-type. In this special case, it base64-decodes the data first and then sends it as an iso-8859-2 encoded string. I am not 100% this is really correct behavior, but I think it is. The check-multipart service seems to have problems with the iso-8859-2 encoded string ("<para>šedé myši</para>") as it returns an empty body element. 3. The expected result for the multipart tests is: <check-multipart boundary="aaaabbbbccccddddeeefffggghhhiiijjjkkkllmmmnop" content-type="multipart/mixed"> ... </check-multipart> However, what I always get from the check-multipart service is this: <check-multipart boundary="aaaabbbbccccddddeeefffggghhhiiijjjkkkllmmmnop" content-type="multipart/mixed; boundary=aaaabbbbccccddddeeefffggghhhiiijjjkkkllmmmnop"> ... </check-multipart> In other words, the boundary is included in the value of the content-type attribute. I am actually surprised you don't get the boundary string in the content-type attribute with Calabash as you must (at least I think) be sending the boundary in the Content-Type header of the multipart message. --- I am also getting one extra header "x_bluecoat_via" with the response message, but I guess that is because of some proxy. We could probably filter out all but Content-* and x_mpp headers from the result after the p:http-request step in the multipart-001-003 test pipelines. Regards, Vojtech
Received on Thursday, 25 February 2010 10:17:43 UTC