[Seaside] random maddening bug - "corrupted" file upload contents
Cyrille Delaunay
cy.delaunay at gmail.com
Fri Dec 22 14:44:37 UTC 2017
Thank you sven for the advice.
I think have been able to reproduce the issue by only playing with
http://localhost:1701/form-test-3
First of all, here are several ways I can retrieve the expected bytes
constituting my file:
- From terminal:
"od -t x1 myfile.zip "
=> gives me: 50 4b 03 04 0a 00 00 00 00 00 7d 53 43 49 00 00
...
(which matches in decimal: 80 75 3 4 10 0 0 0 0 0 125 83 67 73 ... )
- From Pharo:
'myfile.zip' asFileReference binaryReadStreamDo: [ :in | encoding :=
(ZnCharacterEncoder detectEncoding: in upToEnd) ].
(('myfile.zip' asFileReference binaryReadStreamDo:
[ :in | (ZnCharacterReadStream on: in encoding: encoding)
upToEnd ]) copyFrom: 1 to: 40) asOrderedCollection collect: #codePoint"
=> gives me: an OrderedCollection(80 75 3 4 10 0 0 0 0 0 125 83 67 73 0 0
0 0 0 0)
Now, after triggering the upload of this file from
http://localhost:1701/form-test-3,
I have been able to halt in method #executeOneRequestResponseOn:,
and to notice again something that looks wrong regarding the first four
bytes:
[image: Images intégrées 1]
The web interface displayed something confirming this "strange" first bytes
[image: Images intégrées 2]
Right after, I did the exact same upload test again and halt at the same
location.
And this time:
[image: Images intégrées 3]
[image: Images intégrées 4]
Problem is gone !
I am starting to pull out my hair from my head :)
2017-12-22 11:54 GMT+01:00 Sven Van Caekenberghe <sven at stfx.eu>:
> 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 <cy.delaunay at gmail.com>
> 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
> > seaside at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
--
Cyrille Delaunay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171222/039543a5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-12-22 at 9.48.17 AM.png
Type: image/png
Size: 95432 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171222/039543a5/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-12-22 at 3.35.43 PM.png
Type: image/png
Size: 79979 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171222/039543a5/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-12-22 at 3.38.39 PM.png
Type: image/png
Size: 13353 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171222/039543a5/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-12-22 at 3.32.19 PM.png
Type: image/png
Size: 12846 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171222/039543a5/attachment-0007.png>
More information about the seaside
mailing list