
<!DOCTYPE html>

<html>

<head>

<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">

</head>

<body>

<div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">Hi Esteban,</p>

<p dir="auto">Interesting issue. I wasn't even aware of the mixed subtype.</p>

<p dir="auto">As you say, according to the RFC (<a href="https://tools.ietf.org/html/rfc2046" style="color:#3983C4">https://tools.ietf.org/html/rfc2046</a>) the order of the parts is important, so a map wouldn't be a good fit. It needs to be either an ordered collection, a stream, or the map needs to contain order identifiers (e.g. the index of the respective part).</p>

<p dir="auto">If I'm not mistaken, you are saying that the Seaside request wrapper WARequest isn't well suited to representing such contents, and I agree. I had a similar issue once, where I needed to access the raw body data because the request was being sent with the wrong MIME type and I had to patch WARequest with extension methods.</p>

<p dir="auto">I wonder how the Java Servlet API does this. I guess they have different adaptors...</p>

<p dir="auto">So maybe we need to think about making WARequest more versatile?</p>

<br><p dir="auto">In addition to that, there are many other subtypes of multipart that Seaside does not understand and they should be handled with a proper exception.</p>

<br><p dir="auto">Cheers,<br>

Max</p>

<br><p dir="auto">On 16 Feb 2021, at 19:44, Esteban Maringolo wrote:</p>

</div>

<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div id="65DFB086-DE16-40CF-B571-FCDFB91698A3"><div dir="ltr"><div>Hi all,</div><div><br></div><div>Trying to reproduce in Pharo 8 and Zinc an issue found in VAST (affecting its own subclass of WAServerAdaptor), I found that in Pharo there is a message not understood when processing a "multipart/mixed" kind of request.</div><div><br><a href="https://github.com/SeasideSt/Seaside/issues/1241">https://github.com/SeasideSt/Seaside/issues/1241</a><br></div><div><br></div><div>At this point I don't know whether such request is meaningful, in the context of a web http use it is certainly not likely you'll get such MIME type, but in the context of a REST API, it is not uncommon to have a multipart/mixed that is not a multipart/form-data kind of request you have when using a web form.</div><div><br></div><div>The limitation I see in such use with Seaside, is that WARequest only considers aString as its body, and not a multipart entity, as Zinc and VAST SST properly do in their "native" HTTP request classes.</div><div><br></div><div>As a workaround the adaptor could convert each part of the multipart to a key->value association in the postFields of the WARequest (the key being the "name" of the part), but that would not be semantically correct; OTOH if there is no such mapping then the parts in the multiparts would not be reachable from the WARequest instance.</div><div><br></div><div>Is this a bug or a feature?</div><div><br></div><div>Best regards!</div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Esteban A. Maringolo</div></div></div></div></blockquote>

<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">

</blockquote><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">_______________________________________________<br>

seaside-dev mailing list<br>

seaside-dev@lists.squeakfoundation.org<br>

<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" style="color:#777">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a></p>

</blockquote></div>

</div>

</body>

</html>