<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Cyrille,<div class=""><br class=""></div><div class="">I wrote a file like this:</div><div class=""><br class=""></div><div class="">FileLocator temp / 'myzip.zip' writeStreamDo: [ :out | </div><div class=""> out binary; nextPutAll: #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 0 0 0 0 0 0] ].<br class=""><br class="">Which I can read as follows:</div><div class=""><br class="">FileLocator temp / 'myzip.zip' binaryReadStreamDo: [ :in | in upToEnd ].<br class=""><br class=""></div><div class=""> => #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 0 0 0 0 0 0]<br class=""><br class="">If I upload this file to <a href="http://localhost:1701/form-test-3" class="">http://localhost:1701/form-test-3</a> this works perfectly (macOS 10.13.2 Pharo #60402, Safari. Firefox & Chrome), first time and second time.</div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="BCC630B7-3C70-4C79-998D-28E57D3C90CE" src="cid:4ED4BE5C-635F-4D83-8F14-241F72AB44C1" class=""></div><div class=""><br class=""></div><div class="">Maybe you should try on a co-workers machine just to make sure it is not a local problem on your machine ?</div><div class=""><br class=""></div><div class="">Sven</div><div class=""><br class=""><blockquote type="cite" class="">On 22 Dec 2017, at 15:44, Cyrille Delaunay <<a href="mailto:cy.delaunay@gmail.com" class="">cy.delaunay@gmail.com</a>> wrote:<br class=""><br class="">Thank you sven for the advice.<br class="">I think have been able to reproduce the issue by only playing with <br class=""><br class=""><a href="http://localhost:1701/form-" class="">http://localhost:1701/form-</a>test-3<br class=""><br class="">First of all, here are several ways I can retrieve the expected bytes constituting my file:<br class="">- From terminal: <br class="">"od -t x1 myfile.zip "<br class="">=> gives me: 50 4b 03 04 0a 00 00 00 00 00 7d 53 43 49 00 00 ...<br class="">(which matches in decimal: 80 75 3 4 10 0 0 0 0 0 125 83 67 73 ... )<br class=""><br class="">- From Pharo:<br class="">'myfile.zip' asFileReference binaryReadStreamDo: [ :in | encoding := (ZnCharacterEncoder detectEncoding: in upToEnd) ].<br class="">(('myfile.zip' asFileReference binaryReadStreamDo:<br class=""> [ :in | (ZnCharacterReadStream on: in encoding: encoding) upToEnd ]) copyFrom: 1 to: 40) asOrderedCollection collect: #codePoint"<br class="">=> gives me: an OrderedCollection(80 75 3 4 10 0 0 0 0 0 125 83 67 73 0 0 0 0 0 0)<br class=""><br class=""><br class="">Now, after triggering the upload of this file from http://localhost:1701/form-test-3, <br class="">I have been able to halt in method #executeOneRequestResponseOn:,<br class="">and to notice again something that looks wrong regarding the first four bytes:<br class=""><br class=""><span id="cid:ii_1607ea1f1a6aa65e"><Screen Shot 2017-12-22 at 9.48.17 AM.png></span><br class=""><br class="">The web interface displayed something confirming this "strange" first bytes<br class=""><br class=""><span id="cid:ii_1607ea43a15e653e"><Screen Shot 2017-12-22 at 3.32.19 PM.png></span><br class=""><br class=""><br class=""> Right after, I did the exact same upload test again and halt at the same location.<br class="">And this time:<br class=""><br class=""><span id="cid:ii_1607ea7bf4cc3dc4"><Screen Shot 2017-12-22 at 3.35.43 PM.png></span><br class=""><br class=""><br class=""><span id="cid:ii_1607ea9b07e490cc"><Screen Shot 2017-12-22 at 3.38.39 PM.png></span><br class=""><br class=""><br class="">Problem is gone !<br class="">I am starting to pull out my hair from my head :)<br class=""><br class="">2017-12-22 11:54 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:<br class="">Cyril,<br class=""><br class="">If you think something is wrong with the low level Zinc implementation, you could try without Seaside.<br class=""><br class="">ZnServer startDefaultOn: 1701.<br class=""><br class="">http://localhost:1701/form-test-3<br class=""><br class="">You could try to debug/inspect from #formTest3:<br class=""><br class="">HTH,<br class=""><br class="">Sven<br class=""><br class="">> On 22 Dec 2017, at 11:38, Cyrille Delaunay <cy.delaunay@gmail.com> wrote:<br class="">><br class="">> Hi everyone,<br class="">><br class="">> Since some times, we are experimenting a random bug while using seaside file upload.<br class="">> Not sure at all about the exact origin of this issue (Application specific, Zinc, Seaside, Pharo ?).<br class="">> But as it start to drive us mad, I'm sharing our problem with you.<br class="">> Maybe someone would already have experimented something similar or would have a good feeling about the issue.<br class="">><br class="">> High level description:<br class="">><br class="">> We have a file upload element rendered with seaside.<br class="">> The callback of this file upload element is triggered when the form is submitted via a submit button.<br class="">> Problem: Within this callback, the raw contents of the WAFile does not match the expected contents of the selected file.<br class="">> The first 4 bytes are "wrong", and rest of the byte array seems ok.<br class="">> This issue occurs randomly and we haven't been able to determine / guess any context criteria.<br class="">><br class="">><br class="">> Debugging:<br class="">><br class="">> 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.<br class="">><br class="">> The earlier upload step in which we have been able to notice this delta, is method<br class="">><br class="">> ZnMultiThreadedServer >> executeOneRequestResponseOn:<br class="">><br class="">> In this method, a http request is read and materialized from an input stream,<br class="">> From my naive point of vue, this stream looks like a kind of communication entry point between the web browser and pharo.<br class="">><br class="">> The zip input file I am trying to upload is expected to begin with the following bytes:<br class="">> #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 ...<br class="">><br class="">> The request object built within #executeOneRequestResponseOn: points to an"entity" variable, which points to a "parts" variable, which points to a single ZnMimePart.<br class="">> This ZnMimePart points to a byte array beginning with:<br class="">> #[0 0 0 0 10 0 0 0 0 0 125 83 67 73 ...<br class="">><br class="">> I also experimented another case where<br class="">> The request object built within #executeOneRequestResponseOn: points to an"entity" variable, which points to a "parts" variable, which points to multiple ZnMimePart.<br class="">> One of the ZnMimePart points to a byte array beginning with:<br class="">> #[138 67 80 75 10 0 0 0 0 0 125 83 67 73<br class="">><br class="">> We can see that in both cases the first 4 bytes do not match the expected first 4 bytes of the file.<br class="">> As a consequence, later in our process,<br class="">> pharo gets a error while trying to unzip this upload file, complaining about a "'bad LH signature at 0'".<br class="">><br class="">><br class="">> Does this speak to anyone ?<br class="">><br class="">><br class="">><br class="">> --<br class="">> Cyrille Delaunay<br class="">> _______________________________________________<br class="">> seaside mailing list<br class="">> seaside@lists.squeakfoundation.org<br class="">> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br class=""><br class="">_______________________________________________<br class="">seaside mailing list<br class="">seaside@lists.squeakfoundation.org<br class="">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br class=""><br class=""><br class=""><br class="">-- <br class="">Cyrille Delaunay<br class="">_______________________________________________<br class="">seaside mailing list<br class="">seaside@lists.squeakfoundation.org<br class="">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside<br class=""></blockquote><br class=""></div></body></html>