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

Cyrille Delaunay cy.delaunay at gmail.com
Tue Jan 2 13:59:30 UTC 2018


I pushed a bit further.
I executed the above scenario with an ubuntu virtual machine and firefox.
I reproduced the issue.

I also know that co-workers running Windows also faced the general issue.

So I would be tempted to exclude OS or web browser specificities.



2018-01-02 12:53 GMT+01:00 Cyrille Delaunay <cy.delaunay at gmail.com>:

> 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 <http://37.139.2.203/redmine/issues/906/edit> Saisir temps
> <http://37.139.2.203/redmine/issues/906/time_entries/new> Surveiller
> <http://37.139.2.203/redmine/watchers/watch?object_id=906&object_type=issue>
>  Copier <http://37.139.2.203/redmine/projects/general/issues/906/copy>
> Supprimer <http://37.139.2.203/redmine/issues/906>
>
>
> 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 !
>
> 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
>



-- 
Cyrille Delaunay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20180102/ccbcb652/attachment-0001.html>


More information about the seaside mailing list