From emaringolo at gmail.com Tue Feb 16 18:44:25 2021 From: emaringolo at gmail.com (Esteban Maringolo) Date: Tue, 16 Feb 2021 15:44:25 -0300 Subject: [Seaside-dev] Error in ZnZincServerAdaptor when extracting the body in a multipart/mixed request Message-ID: Hi all, 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. https://github.com/SeasideSt/Seaside/issues/1241 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. 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. 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. Is this a bug or a feature? Best regards! Esteban A. Maringolo -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxleske at gmail.com Wed Feb 17 06:18:13 2021 From: maxleske at gmail.com (Max Leske) Date: Wed, 17 Feb 2021 07:18:13 +0100 Subject: [Seaside-dev] Error in ZnZincServerAdaptor when extracting the body in a multipart/mixed request In-Reply-To: References: Message-ID: Hi Esteban, Interesting issue. I wasn't even aware of the mixed subtype. As you say, according to the RFC (https://tools.ietf.org/html/rfc2046) 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). 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. I wonder how the Java Servlet API does this. I guess they have different adaptors... So maybe we need to think about making WARequest more versatile? 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. Cheers, Max On 16 Feb 2021, at 19:44, Esteban Maringolo wrote: > Hi all, > > 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. > > https://github.com/SeasideSt/Seaside/issues/1241 > > 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. > > 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. > > 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. > > Is this a bug or a feature? > > Best regards! > > Esteban A. Maringolo > _______________________________________________ > seaside-dev mailing list > seaside-dev at lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: