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