<div dir="ltr">Hi everyone,<div><br></div><div>Since some times, we are experimenting a random bug while using seaside file upload.</div><div>Not sure at all about the exact origin of this issue (Application specific, Zinc, Seaside, Pharo ?).</div><div>But as it start to drive us mad, I'm sharing our problem with you.</div><div>Maybe someone would already have experimented something similar or would have a good feeling about the issue.</div><div><br></div><div><b>High level description:</b></div><div><br></div><div>We have a file upload element rendered with seaside.</div><div>The callback of this file upload element is triggered when the form is submitted via a submit button.</div><div>Problem: Within this callback, the raw contents of the WAFile does not match the expected contents of the selected file.</div><div>The first 4 bytes are "wrong", and rest of the byte array seems ok.</div><div>This issue occurs randomly and we haven't been able to determine / guess any context criteria.</div><div><div><br></div><div><br></div><div><b>Debugging:</b></div><div><br></div><div>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.</div><div><br></div><div>The earlier upload step in which we have been able to notice this delta, is method <br></div><div><div><br></div><div>ZnMultiThreadedServer >> executeOneRequestResponseOn:</div><div><br></div><div>In this method, a http request is read and materialized from an input stream, </div><div>From my naive point of vue, this stream looks like a kind of communication entry point between the web browser and pharo.</div><div><br></div><div>The zip input file I am trying to upload is expected to begin with the following bytes:  </div><div>#[80 75 3 4 10 0 0 0 0 0 125 83 67 73 ...</div><div><br></div><div>The request object built within #executeOneRequestResponseOn:  points to an"entity" variable, which points to a "parts" variable, which points to a single ZnMimePart.</div><div>This ZnMimePart points to a byte array beginning with:  </div><div>#[0 0 0 0 10 0 0 0 0 0 125 83 67 73 ...</div><div><br></div><div>I also experimented another case where </div><div>The request object built within #executeOneRequestResponseOn:  points to an"entity" variable, which points to a "parts" variable, which points to multiple ZnMimePart.</div><div>One of the ZnMimePart points to a byte array beginning with: </div><div>#[138 67 80 75 10 0 0 0 0 0 125 83 67 73</div><div><br></div><div>We can see that in both cases the first 4 bytes do not match the expected first 4 bytes of the file.</div><div>As a consequence, later in our process, </div><div>pharo gets a error while trying to unzip this upload file, complaining about a "'bad LH signature at 0'".</div><div><br></div><div><br></div><div>Does this speak to anyone ?</div><div><br></div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Cyrille Delaunay</div></div></div>
</div></div>