0x0 character in html response string

> Hi,
>
> In some circumstances, I'm getting a '0x0' character at the end of the class attribute in my webpage.
> This character is interfering with class matching for rendering and jQuery selection. In xhtml mode, it even crashes the page parsing.
>
> Here is an example of class attribute with the 0x0 char:
>
> class="decoration status-confirmedoption decoration-VerhuurA groupstart group-1283859969 group-1558129409� ui-selectee ui-droppable ui-draggable ui-selected"
>
> The classes after the 0x0 character were added by jQuery after page load.
>
> Although I can repeat the problem deterministically, I do not find the discriminating behavior with respect to class attributes of other elements.
> The most common factor I found is that the character gets inserted when the string is 99 characters long.... add or remove a character and the 0x0 goes away.
>
> The really strange part is that:
> - I do not see the character when inspecting the response string that is served on the server
> - I do not see the character when using an HTTP client (Zinc) to get the raw response
> - I do not see the character in the page source when choosing 'page source' from the developers menu in Chrome
> But maybe the above is just because character encoding is covering up for it...
>
> The problem occurs both on Firefox and Chrome, even with javascript turned off (to ensure that it's the bare page rendering).
>
> I am only seeing this on GemStone...
>
> Does this ring a bell with anyone?
>
> Johan

> So... the 99 position was the problem was the key.
> It appears this is a problem in the package override by Zinc of #streamContents:
>
> The override rewrites #streamContents: to #new:streamContents: like this:
>
> new: newSize streamContents: blockWithArg
>
> | stream |
> stream := WriteStream on: (self new: newSize).
> blockWithArg value: stream.
> stream position = newSize
> ifTrue: [ ^stream originalContents ]
> ifFalse: [ ^stream contents ]
>
>
> But because of the different stream positioning in Gemstone (wrt Squeak/Pharo), it should be this:
>
> new: newSize streamContents: blockWithArg
>
> | stream |
> stream := WriteStream on: (self new: newSize).
> blockWithArg value: stream.
> stream position - 1 = newSize
> ifTrue: [ ^stream originalContents ]
> ifFalse: [ ^stream contents ]
>
>
> Damn... that took me a while to discover!!
>
> Johan
>
> On 11 Jul 2011, at 19:15, Johan Brichau wrote:
>
>> Hi,
>>
>> In some circumstances, I'm getting a '0x0' character at the end of the class attribute in my webpage.
>> This character is interfering with class matching for rendering and jQuery selection. In xhtml mode, it even crashes the page parsing.
>>
>> Here is an example of class attribute with the 0x0 char:
>>
>> class="decoration status-confirmedoption decoration-VerhuurA groupstart group-1283859969 group-1558129409� ui-selectee ui-droppable ui-draggable ui-selected"
>>
>> The classes after the 0x0 character were added by jQuery after page load.
>>
>> Although I can repeat the problem deterministically, I do not find the discriminating behavior with respect to class attributes of other elements.
>> The most common factor I found is that the character gets inserted when the string is 99 characters long.... add or remove a character and the 0x0 goes away.
>>
>> The really strange part is that:
>> - I do not see the character when inspecting the response string that is served on the server
>> - I do not see the character when using an HTTP client (Zinc) to get the raw response
>> - I do not see the character in the page source when choosing 'page source' from the developers menu in Chrome
>> But maybe the above is just because character encoding is covering up for it...
>>
>> The problem occurs both on Firefox and Chrome, even with javascript turned off (to ensure that it's the bare page rendering).
>>
>> I am only seeing this on GemStone...
>>
>> Does this ring a bell with anyone?
>>
>> Johan
>