W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > February 2010

RE: Multipart tests

From: <Toman_Vojtech@emc.com>
Date: Thu, 25 Feb 2010 05:16:55 -0500
Message-ID: <997C307BEB90984EBE935699389EC41CCDF73B@CORPUSMX70C.corp.emc.com>
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!


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.

However, if I remove the "This is a message..." line:


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"

The expected test result contains the following:

      <header name="Content-Transfer-Encoding">base64</header>
      <header name="Content-Type">text/plain; charset=iso-8859-2</header>

However, this is not what I get with Calumet. What I get is this: 

<header name="Content-Type">text/plain; charset=iso-8859-2</header>

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

However, what I always get from the check-multipart service is this:

<check-multipart boundary="aaaabbbbccccddddeeefffggghhhiiijjjkkkllmmmnop"
    content-type="multipart/mixed; boundary=aaaabbbbccccddddeeefffggghhhiiijjjkkkllmmmnop">

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.

Received on Thursday, 25 February 2010 10:17:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:48 UTC