Re: random maddening bug - "corrupted" file upload contents

Cyril,

If you think something is wrong with the low level Zinc implementation, you could try without Seaside.

ZnServer startDefaultOn: 1701.

http://localhost:1701/form-test-3

You could try to debug/inspect from #formTest3:

HTH,

Sven

> On 22 Dec 2017, at 11:38, Cyrille Delaunay <[email protected]> wrote:
> 
> Hi everyone,
> 
> Since some times, we are experimenting a random bug while using seaside file upload.
> Not sure at all about the exact origin of this issue (Application specific, Zinc, Seaside, Pharo ?).
> But as it start to drive us mad, I'm sharing our problem with you.
> Maybe someone would already have experimented something similar or would have a good feeling about the issue.
> 
> High level description:
> 
> We have a file upload element rendered with seaside.
> The callback of this file upload element is triggered when the form is submitted via a submit button.
> Problem: Within this callback, the raw contents of the WAFile does not match the expected contents of the selected file.
> The first 4 bytes are "wrong", and rest of the byte array seems ok.
> This issue occurs randomly and we haven't been able to determine / guess any context criteria.
> 
> 
> Debugging:
> 
> In order to figure out what was wrong, we tried to catch a place in pharo where file contents started to differ from the expected file contents.
> 
> The earlier upload step in which we have been able to notice this delta, is method 
> 
> ZnMultiThreadedServer >> executeOneRequestResponseOn:
> 
> In this method, a http request is read and materialized from an input stream, 
> From my naive point of vue, this stream looks like a kind of communication entry point between the web browser and pharo.
> 
> The zip input file I am trying to upload is expected to begin with the following bytes:  
> #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 ...
> 
> The request object built within #executeOneRequestResponseOn:  points to an"entity" variable, which points to a "parts" variable, which points to a single ZnMimePart.
> This ZnMimePart points to a byte array beginning with:  
> #[0 0 0 0 10 0 0 0 0 0 125 83 67 73 ...
> 
> I also experimented another case where 
> The request object built within #executeOneRequestResponseOn:  points to an"entity" variable, which points to a "parts" variable, which points to multiple ZnMimePart.
> One of the ZnMimePart points to a byte array beginning with: 
> #[138 67 80 75 10 0 0 0 0 0 125 83 67 73
> 
> We can see that in both cases the first 4 bytes do not match the expected first 4 bytes of the file.
> As a consequence, later in our process, 
> pharo gets a error while trying to unzip this upload file, complaining about a "'bad LH signature at 0'".
> 
> 
> Does this speak to anyone ?
> 
> 
> 
> -- 
> Cyrille Delaunay
> _______________________________________________
> seaside mailing list
> [email protected]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[email protected]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside