[Seaside] random maddening bug - "corrupted" file upload contents

[Cyrille Delaunay]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171222/61159281/attachment.html>