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!

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 25 February 2010 10:17:43 GMT