Hi Christoph,

On Sat, 5 Sep 2020, Thiede, Christoph wrote:

> 
> Hi all,
> 
> 
> while doing some experiments with WebClient & WebUtils in order to send textual data to a server via HTTP(S), I found out that posting a request containing non-ASCII characters in a multipart/form-data yields a primitive
> failure from SqueakSSL/primitiveEncrypt (occurs on both Win32 + emulated Linux/Ubuntu). When I converted the text manually using #squeakToUtf8 before putting it into the contents data, everything worked fine and the server
> receives the correct text without any encoding problems.
> 
> 
> So for my application, I can manually #squeakToUtf8-convert the request string before posting it, but I wonder whether this should really be the responsibility of every Squeak developer and not rather one of the WebClient?
> For illustration: If you use normal #htmlSubmit:fields: instead of #httpPost:multipartFields:, WebClient does all necessary conversion (#encodeUrlEncodedForm:, String >> #encodeForHTTP) itself. Anyway,
> #encodeMultipartForm:boundary: does not care about conversion.
> 
> 
> I am only a bloody newbie to all this web stuff, so maybe I am missing something important. What do you think? Should we add #squeakToUtf8 conversion in WebUtils class >> #encodeMultipartForm:boundary:, and in the decode
> message vice versa? Or would this rather be a responsibility of the SqueakSSL protocol? I am looking forward to your help!

Encoding is definitely missing there. multipart/form-data is a mess [1]
though, so we should be careful to generate what presumably everything 
supports but be able to parse what other sources can generate.


Levente
[1] https://tools.ietf.org/html/rfc7578

> 
> 
> Best,
> 
> Christoph
> 
> 
>