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

Re: Multipart tests

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 25 Feb 2010 08:32:47 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2ljehwidc.fsf@nwalsh.com>
"Toman_Vojtech@emc.com" <Toman_Vojtech@emc.com> writes:
> 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.

Fixed, I think. Please let me know.

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

That's what I was doing too, but then I couldn't decide if that was
right. I don't think it's *wrong* to send the data with a
content-transfer-encoding, but possibly it wouldn't be wrong to
decoded it and send the octets as well.

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

Yeah. I'm not sure how to parse the iso-8859-2 text in my little Perl
progam. Especially not without a content-length to tell me how long it

I don't have any problem if you want to assert that you pass the test
even though the test report says it fails. I have the same problem with

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

Yeah, I got that totally wrong :-)


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

Sure. Or just live with the fact that your test is a pass even though
the results look like it isn't. Oh, heck, I'll just filter out the
bluecoat_via header :-) "Fixed."

                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com> | I don't make predictions. I never have
http://nwalsh.com/            | and I never will.--Tony Blair

Received on Thursday, 25 February 2010 13:33:22 UTC

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