Smalltalk › Frameworks & Tools › Seaside › Seaside Development

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Esteban A. Maringolo

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

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

Max Leske

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

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