- 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
is.
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
validxsd-006.
> 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 :-)
Fixed.
> 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,
norm
--
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