Error in ZnZincServerAdaptor when extracting the body in a multipart/mixed request

Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Error in ZnZincServerAdaptor when extracting the body in a multipart/mixed request

Esteban A. Maringolo
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.

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: Error in ZnZincServerAdaptor when extracting the body in a multipart/mixed request

Max Leske

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.

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
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

signature.asc (849 bytes) Download Attachment