From voxkmp at gmail.com  Fri Dec  8 12:07:21 2017
From: voxkmp at gmail.com (kmo)
Date: Fri, 8 Dec 2017 05:07:21 -0700 (MST)
Subject: [Seaside] Rendering pre-formatted html
Message-ID: <1512734841466-0.post@n4.nabble.com>

How do I render a piece of pre-written html in Seaside?

For example, if I have:

renderContentOn: html

| htmlFragment |
	htmlFragment := 'I  am renderedas text>'.
	
Then how do I render this as html code rather than as a literal string?

Thanks in advance for any help. 



--
Sent from: http://forum.world.st/Seaside-General-f86180.html

From voxkmp at gmail.com  Fri Dec  8 12:09:46 2017
From: voxkmp at gmail.com (kmo)
Date: Fri, 8 Dec 2017 05:09:46 -0700 (MST)
Subject: [Seaside] Rendering pre-formatted html
In-Reply-To: <1512734841466-0.post@n4.nabble.com>
References: <1512734841466-0.post@n4.nabble.com>
Message-ID: <1512734986245-0.post@n4.nabble.com>

Sorry - the string came out as html!! - the very effect I'm trying to
emulate! The htmlFragment is a string with html tags in it.



--
Sent from: http://forum.world.st/Seaside-General-f86180.html

From thomas.brodt.lists at porabo.ch  Fri Dec  8 12:31:21 2017
From: thomas.brodt.lists at porabo.ch (Thomas Brodt)
Date: Fri, 8 Dec 2017 13:31:21 +0100
Subject: [Seaside] Rendering pre-formatted html
In-Reply-To: <1512734986245-0.post@n4.nabble.com>
References: <1512734841466-0.post@n4.nabble.com>
 <1512734986245-0.post@n4.nabble.com>
Message-ID: <2132db83-1407-f051-86ac-bfbd0c39356a@porabo.ch>

if you invoke the following to the html argument of the render method

renderContentOn: html

     html html: '<p>paragraph</p>'

the content is added to the html stream as is.

HTH

Thomas


Am 08.12.2017 um 13:09 schrieb kmo:
> Sorry - the string came out as html!! - the very effect I'm trying to
> emulate! The htmlFragment is a string with html tags in it.
>
>
>
> --
> Sent from: http://forum.world.st/Seaside-General-f86180.html
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


From voxkmp at gmail.com  Fri Dec  8 12:56:43 2017
From: voxkmp at gmail.com (kmo)
Date: Fri, 8 Dec 2017 05:56:43 -0700 (MST)
Subject: [Seaside] Rendering pre-formatted html
In-Reply-To: <2132db83-1407-f051-86ac-bfbd0c39356a@porabo.ch>
References: <1512734841466-0.post@n4.nabble.com>
 <1512734986245-0.post@n4.nabble.com>
 <2132db83-1407-f051-86ac-bfbd0c39356a@porabo.ch>
Message-ID: <1512737803013-0.post@n4.nabble.com>

Thank ou very much. That's great.



--
Sent from: http://forum.world.st/Seaside-General-f86180.html

From david at totallyobjects.com  Tue Dec 19 13:30:25 2017
From: david at totallyobjects.com (David Pennington)
Date: Tue, 19 Dec 2017 13:30:25 +0000
Subject: [Seaside] What does "Signal:1" mean?
Message-ID: <44c9188e4f41574e9e8beaec79123969@totallyobjects.com>

I am testing my Seaside development - Instantiations VAST 9.0 - and I am getting "Signal: 1" as an error. The problem is that the stack doesn't tell me where the error is, or at least not that I can understand. I attach a screen shot and the stack trace. Can anyone help me understand this please?
DavidTotally Objects

Message sent using Winmail Mail Server
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171219/6eecd25b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-12-19 at 13.26.26.png
Type: image/png
Size: 66499 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171219/6eecd25b/attachment-0001.png>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stack.txt
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171219/6eecd25b/attachment-0001.txt>

From jtuchel at objektfabrik.de  Tue Dec 19 13:35:14 2017
From: jtuchel at objektfabrik.de (Joachim Tuchel)
Date: Tue, 19 Dec 2017 14:35:14 +0100 (CET)
Subject: [Seaside] What does "Signal:1" mean?
In-Reply-To: <44c9188e4f41574e9e8beaec79123969@totallyobjects.com>
References: <44c9188e4f41574e9e8beaec79123969@totallyobjects.com>
Message-ID: <1074639607.37270.1513690514941@ox.hosteurope.de>

David


I guess you should take a closer look at this part of the Stack:


OrderedCollection(SequenceableCollection)>>#first self=OrderedCollection()

OrderedCollection>>#first self=OrderedCollection() TM470User>>#carCardForRoadNumber: self=a TM470User id='BM:33549'

[] in TM470CurrentTrain>>#constructCarsUsing: self=a TM470CurrentTrain aUser=a TM470User carArray=OrderedCollection('BM:33549' 'BAR:6724' 'CP:240000'


Seems like you try to use the first element in an empty Collection. Not related to Seaside, afaik.


Joachim


> David Pennington <david at totallyobjects.com> hat am 19. Dezember 2017 um 14:30 geschrieben:
> 
>     I am testing my Seaside development - Instantiations VAST 9.0 - and I am getting "Signal: 1" as an error. The problem is that the stack doesn't tell me where the error is, or at least not that I can understand. I attach a screen shot and the stack trace. Can anyone help me understand this please?
> 
>     David
>     Totally Objects
>      
> 


 

> 
>     ---------------------------------------------
> 
>     Message sent using Winmail Mail Server
> 
>     _______________________________________________
>     seaside mailing list
>     seaside at lists.squeakfoundation.org
>     http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> 


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171219/945dce2a/attachment.html>

From david at totallyobjects.com  Tue Dec 19 13:38:47 2017
From: david at totallyobjects.com (David Pennington)
Date: Tue, 19 Dec 2017 13:38:47 +0000
Subject: [Seaside] What does "Signal:1" mean?
Message-ID: <bfd082362df43120a4fc5ebd7fb2b394@totallyobjects.com>

Oh, shucks. Didn't open the stack up far enough! Back to the drawing board (or keyboard!).
Thanks Joachim. Note to self: check the obvious first! (I wouldn't mind but I have been writing Smalltalk for 27 years so I should know this).
David

--------- Original Message ---------
From: "Joachim Tuchel" <jtuchel at objektfabrik.de>
To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>, "David Pennington" <david at totallyobjects.com>
Subject: Re: [Seaside] What does "Signal:1" mean?
Date: 12/19/2017 13:35:58 (Tue)

David

I guess you should take a closer look at this part of the Stack:

OrderedCollection(SequenceableCollection)>>#first self=OrderedCollection() 

OrderedCollection>>#first self=OrderedCollection() TM470User>>#carCardForRoadNumber: self=a TM470User id='BM:33549' 

[] in TM470CurrentTrain>>#constructCarsUsing: self=a TM470CurrentTrain aUser=a TM470User carArray=OrderedCollection('BM:33549' 'BAR:6724' 'CP:240000' 

Seems like you try to use the first element in an empty Collection. Not related to Seaside, afaik.

Joachim

David Pennington  hat am 19. Dezember 2017 um 14:30 geschrieben: 

I am testing my Seaside development - Instantiations VAST 9.0 - and I am getting "Signal: 1" as an error. The problem is that the stack doesn't tell me where the error is, or at least not that I can understand. I attach a screen shot and the stack trace. Can anyone help me understand this please?
DavidTotally Objects 

Message sent using Winmail Mail Server_______________________________________________ 
seaside mailing list 
seaside at lists.squeakfoundation.org 
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside 

Message sent using Winmail Mail Server
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171219/83d2e96d/attachment.html>

From cy.delaunay at gmail.com  Fri Dec 22 10:38:15 2017
From: cy.delaunay at gmail.com (Cyrille Delaunay)
Date: Fri, 22 Dec 2017 11:38:15 +0100
Subject: [Seaside] random maddening bug - "corrupted" file upload contents
Message-ID: <CAMEdb_BDM2O7TJGb4EHouABtWKqh1SvnsWEd2fMNmMyS=wxkMQ@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171222/61159281/attachment.html>

From sven at stfx.eu  Fri Dec 22 10:54:18 2017
From: sven at stfx.eu (Sven Van Caekenberghe)
Date: Fri, 22 Dec 2017 11:54:18 +0100
Subject: [Seaside] random maddening bug - "corrupted" file upload
	contents
In-Reply-To: <CAMEdb_BDM2O7TJGb4EHouABtWKqh1SvnsWEd2fMNmMyS=wxkMQ@mail.gmail.com>
References: <CAMEdb_BDM2O7TJGb4EHouABtWKqh1SvnsWEd2fMNmMyS=wxkMQ@mail.gmail.com>
Message-ID: <CE08B3B3-DBC5-4FCC-A990-813A75134F55@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


From cy.delaunay at gmail.com  Fri Dec 22 14:44:37 2017
From: cy.delaunay at gmail.com (Cyrille Delaunay)
Date: Fri, 22 Dec 2017 15:44:37 +0100
Subject: [Seaside] random maddening bug - "corrupted" file upload
	contents
In-Reply-To: <CE08B3B3-DBC5-4FCC-A990-813A75134F55@stfx.eu>
References: <CAMEdb_BDM2O7TJGb4EHouABtWKqh1SvnsWEd2fMNmMyS=wxkMQ@mail.gmail.com>
 <CE08B3B3-DBC5-4FCC-A990-813A75134F55@stfx.eu>
Message-ID: <CAMEdb_DM91-WUjAmdzeEwfBe+i1gEom03VLdcEtwnApPF58y8A@mail.gmail.com>

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>

From sven at stfx.eu  Fri Dec 22 16:49:58 2017
From: sven at stfx.eu (Sven Van Caekenberghe)
Date: Fri, 22 Dec 2017 17:49:58 +0100
Subject: [Seaside] random maddening bug - "corrupted" file upload
	contents
In-Reply-To: <CAMEdb_DM91-WUjAmdzeEwfBe+i1gEom03VLdcEtwnApPF58y8A@mail.gmail.com>
References: <CAMEdb_BDM2O7TJGb4EHouABtWKqh1SvnsWEd2fMNmMyS=wxkMQ@mail.gmail.com>
 <CE08B3B3-DBC5-4FCC-A990-813A75134F55@stfx.eu>
 <CAMEdb_DM91-WUjAmdzeEwfBe+i1gEom03VLdcEtwnApPF58y8A@mail.gmail.com>
Message-ID: <28C822F0-57F9-4989-A00D-A4AC5C6A6A78@stfx.eu>

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 ?

Sven

> On 22 Dec 2017, at 15:44, Cyrille Delaunay <cy.delaunay at gmail.com> wrote:
> 
> 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:
> 
> <Screen Shot 2017-12-22 at 9.48.17 AM.png>
> 
> The web interface displayed something confirming this "strange" first bytes
> 
> <Screen Shot 2017-12-22 at 3.32.19 PM.png>
> 
> 
>  Right after, I did the exact same upload test again and halt at the same location.
> And this time:
> 
> <Screen Shot 2017-12-22 at 3.35.43 PM.png>
> 
> 
> <Screen Shot 2017-12-22 at 3.38.39 PM.png>
> 
> 
> 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
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171222/59668eae/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-12-22 at 17.48.31.png
Type: image/png
Size: 22409 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171222/59668eae/attachment-0001.png>

From cyril.ferlicot at gmail.com  Fri Dec 22 17:00:50 2017
From: cyril.ferlicot at gmail.com (Cyril Ferlicot)
Date: Fri, 22 Dec 2017 17:00:50 +0000
Subject: [Seaside] random maddening bug - "corrupted" file upload
	contents
In-Reply-To: <28C822F0-57F9-4989-A00D-A4AC5C6A6A78@stfx.eu>
References: <CAMEdb_BDM2O7TJGb4EHouABtWKqh1SvnsWEd2fMNmMyS=wxkMQ@mail.gmail.com>
 <CE08B3B3-DBC5-4FCC-A990-813A75134F55@stfx.eu>
 <CAMEdb_DM91-WUjAmdzeEwfBe+i1gEom03VLdcEtwnApPF58y8A@mail.gmail.com>
 <28C822F0-57F9-4989-A00D-A4AC5C6A6A78@stfx.eu>
Message-ID: <CAMyorgAxj4RFLn1CwXaamwfwR2zU1bNvDDVeiDSTaUCPhnBrDg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171222/a26f7474/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-12-22 at 17.48.31.png
Type: image/png
Size: 22409 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20171222/a26f7474/attachment-0001.png>

From sven at stfx.eu  Fri Dec 22 17:05:15 2017
From: sven at stfx.eu (Sven Van Caekenberghe)
Date: Fri, 22 Dec 2017 18:05:15 +0100
Subject: [Seaside] random maddening bug - "corrupted" file upload
	contents
In-Reply-To: <CAMyorgAxj4RFLn1CwXaamwfwR2zU1bNvDDVeiDSTaUCPhnBrDg@mail.gmail.com>
References: <CAMEdb_BDM2O7TJGb4EHouABtWKqh1SvnsWEd2fMNmMyS=wxkMQ@mail.gmail.com>
 <CE08B3B3-DBC5-4FCC-A990-813A75134F55@stfx.eu>
 <CAMEdb_DM91-WUjAmdzeEwfBe+i1gEom03VLdcEtwnApPF58y8A@mail.gmail.com>
 <28C822F0-57F9-4989-A00D-A4AC5C6A6A78@stfx.eu>
 <CAMyorgAxj4RFLn1CwXaamwfwR2zU1bNvDDVeiDSTaUCPhnBrDg@mail.gmail.com>
Message-ID: <C019733F-8171-4FFA-9ECB-7F1AD3CF22CD@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