[Seaside] random maddening bug - "corrupted" file upload contents
Cyrille Delaunay
cy.delaunay at gmail.com
Tue Jan 2 19:28:03 UTC 2018
2018-01-02 17:37 GMT+01:00 Sven Van Caekenberghe <sven at stfx.eu>:
>
>
> > On 2 Jan 2018, at 12:53, Cyrille Delaunay <cy.delaunay at gmail.com> wrote:
> >
> > Hi Sven,
> >
> > I am back on this issue :)
> >
> > I have kind of a "clean" scenario that could help to reproduce.
> > It is still random, but at one point, it shows up for me.
> >
> > Here is how I am doing:
> > Download Pharo 6.1 on my Mac (Sierra 10.12.6):
> https://pharo.org/web/download
> > Then, iterate over this process till spotting the issue:
> >
> > => start the pharo image
> > => execute this piece of code in a playground
> >
> > ZnServer startDefaultOn: 1701.
> > ZnServer default maximumEntitySize: 80* 1024 * 1024.
> > '/Users/cdelaunay/myzip.zip' asFileReference writeStreamDo: [ :out |
> > out binary; nextPutAll: #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 0 0 0 0 0
> 0].
> > 18202065 timesRepeat: [ out nextPut: 0 ]
> > ].
> >
> > => Open a web browser page on: http://localhost:1701/form-test-3
> > => Upload the file zip file previously generated ('myzip.zip').
> > => If the web page displays: "contents=000000000a00..." (or anything
> unexpected), THIS IS THE ISSUE !
> > => If the web page displays: "contents=504b03040a00..", the upload
> worked fine. You can close the image (without saving)
> >
> > Mettre à jour Saisir temps Surveiller Copier Supprimer
> >
> >
> > Usually, after starting 3 / 4 times pharo image, I am getting the
> problem.
> > I have been able to reproduce with chrome and firefox.
> >
> >
> > Seing that I was able to reproduce within a fresh pharo image, I tried
> to automate this scenario.
> > I wrote the following test:
> >
> >
> > ZnServerTests >>testFormTest4
> > | inputs client part fileReference fileContents entity |
> > fileReference := 'test-zip.zip' asFileReference.
> > fileReference
> > writeStreamDo: [ :out |
> > out
> > binary;
> > nextPutAll: #[80 75 3 4 10 0 0 0 0 0 125
> 83 67 73 0 0 0 0 0 0].
> > 18202065 timesRepeat: [ out nextPut: 0 ] ].
> > fileContents := fileReference binaryReadStreamDo: [ :in | in
> upToEnd ].
> > 15
> > timesRepeat: [ self
> > withServerDo: [ :server |
> > server maximumEntitySize: 80 *
> 1024 * 1024.
> > server debugMode: true.
> > (client := ZnClient new)
> > url: server localUrl;
> > addPathSegment:
> 'form-test-3'.
> > client timeout: 120000.
> > entity := (ZnByteArrayEntity type:
> (ZnMimeType main: 'application' sub: 'zip') length: fileContents size)
> bytes: fileContents.
> > part := ZnMimePart fieldName:
> 'file' fileName: fileReference basename entity: entity.
> > client
> > resetEntity;
> > addPart: part;
> > post.
> > self assert: client isSuccess.
> > self assert: (client contents
> includesSubstring: '504b03040a') ] ]
> >
> >
> >
> >
> > In order to make this test run correctly I had to modify this method.
> > Without this change, I always got an empty html page as response
> >
> >
> >
> > ZnDefaultServerDelegate >> formTest3: request
> > | contents filename contentType page |
> > contents := filename := contentType := ''.
> > (request hasEntity and: [ request contentType matches: ZnMimeType
> multiPartFormData ])
> > ifTrue: [
> > (request entity partNamed: #file ifNone: [ nil ])
> > ifNotNil: [ :part |
> > filename := part fileName.
> > contents := part contents.
> > contentType := part contentType.
> > contentType isBinary ifTrue: [
> contents := contents hex ] ] ].
> > page := ZnHtmlOutputStream streamContents: [ :html |
> > html page: 'Form Test 3' do: [
> > html
> > tag: #form
> > attributes: #(action 'form-test-3'
> 'accept-charset' 'utf-8'
> >
> enctype 'multipart/form-data' method POST)
> > do: [
> > html
> > str: 'File'; space;
> > tag: #input attributes:
> #(type file name file); space;
> > tag: #input attributes:
> #(type submit) ];
> > tag: #p do: [ html str: 'filename = ';
> str: filename ];
> > tag: #p do: [ html str: 'content-type = ';
> str: contentType asString ];
> > tag: #p do: [ html str: 'contents = ';
> str: (contents copyFrom: 1 to: 20) asString ] ] ].
> > ^ ZnResponse ok: (ZnEntity html: page)
> >
> >
> >
> > Unfortunately, the tests always passed till now !
>
> So you have to upload 80Mb ?
>
Sometimes yes.
But here the file I build and use to reproduce is only 18 mb.
(the same size as the original file highlighting the issue on my machine).
> And if you script it in Pharo and repeat it 15 times it keeps on working ?
> Really ?
>
Yes indeed.
But again, it is completely random.
I could not ensure that the problem would never show up with the script.
I will try to make more tries tomorrow.
>
> It seems that it only fails when a manually operated browser is involved.
>
Yes, exactly
>
> Have you tried doing the upload with curl ?
>
No.
How would I do that ?
>
> > I will try to go on refining the context parameters that could make the
> issue show up or not
> >
> >
> >
> > 2017-12-22 18:05 GMT+01:00 Sven Van Caekenberghe <sven at stfx.eu>:
> > Well, I can't repeat it, for now.
> >
> > Try to make a minimal self-contained example that fails (reliably), like
> how I did it, you can even try to do the upload in Pharo too (see
> #testFormTest3).
> >
> > > On 22 Dec 2017, at 18:00, Cyril Ferlicot <cyril.ferlicot at gmail.com>
> wrote:
> > >
> > >
> > > On ven. 22 déc. 2017 at 17:50, Sven Van Caekenberghe <sven at stfx.eu>
> wrote:
> > > Cyrille,
> > >
> > > I wrote a file like this:
> > >
> > > FileLocator temp / 'myzip.zip' writeStreamDo: [ :out |
> > > out binary; nextPutAll: #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 0 0 0
> 0 0 0] ].
> > >
> > > Which I can read as follows:
> > >
> > > FileLocator temp / 'myzip.zip' binaryReadStreamDo: [ :in | in upToEnd
> ].
> > >
> > > => #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 0 0 0 0 0 0]
> > >
> > > If I upload this file to http://localhost:1701/form-test-3 this works
> perfectly (macOS 10.13.2 Pharo #60402, Safari. Firefox & Chrome), first
> time and second time.
> > >
> > >
> > >
> > > Maybe you should try on a co-workers machine just to make sure it is
> not a local problem on your machine ?
> > >
> > > Hi Sven,
> > >
> > > It happen on Cyrille's machine, my machine, Yann's machine and our
> boss's machine.
> > >
> > > We first saw it on Windows and never on mac/Linux. But now we see it
> also on mac.
> > >
> > > I did not see it yet on Linux but we use it less for now.
> > >
> > > Also, when it happen, it tend to happen a lot afterward.
> > >
> > > Also, by random it means that we can have 1/2 week without problem,
> then 4 failure in 2h.
> > >
> > >
> > >
> > > Sven
> > >
> > > --
> > > Cyril Ferlicot
> > > https://ferlicot.fr
> > >
> > > http://www.synectique.eu
> > > 2 rue Jacques Prévert 01,
> > > 59650 Villeneuve d'ascq France
> > > <Screen Shot 2017-12-22 at 17.48.31.png>_________________
> ______________________________
> > > 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
> > _______________________________________________
> > 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/20180102/51c151fd/attachment-0001.html>
More information about the seaside
mailing list