Opened 15 years ago

Last modified 14 years ago

#5027 closed defect

Build system corrupting compressed layer builds by inserting null characters — at Version 6

Reported by: Adam Peller Owned by: James Burke
Priority: high Milestone: 1.3
Component: ShrinkSafe Version: 0.9
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by Adam Peller)

When doing a build, the compression step is inserting a null character [0x00] whenever it encounters x00 [0x5C 0x78 0x30 0x30]. Seems like IE doesn't like seeing a null in the middle of a stream. Probably best to have a special case and leave x00 alone?

In #5017, the "x00" reference was removed from our source tree. This ticket is to fix ShrinkSafe?.

See also #6628

Change History (6)

comment:1 Changed 14 years ago by alex

Owner: changed from alex to jamestag

I think we only support UTF-8 inputs no matter what. James, are we set up to handle anything like this?

comment:2 Changed 14 years ago by James Burke

Owner: changed from jamestag to James Burke

Yeah, I think alex checked in something into the build scripts a little while back that made sure we did utf-8 through the build system. Does that mean we can close this ticket? I do not know if that sequence was particular to a utf-8-related sequence?

comment:3 Changed 14 years ago by Adam Peller

No, sorry, it was the null JS escape (literally 'x00') that ShrinkSafe? was barfing on, not an ascii=0 in the input stream. It's not common, but it needs to be fixed regardless of the encoding.

comment:4 Changed 14 years ago by Adam Peller

correction, ShrinkSafe? choke on it, IE did. ShrinkSafe? output a null char, which is a single null byte you're ASCII or UTF-8. The easy solution, iirc, was just to leave x00 alone and not try to turn it into a null char.

comment:5 Changed 14 years ago by James Burke

Milestone: 1.2

comment:6 Changed 14 years ago by Adam Peller

Description: modified (diff)
Note: See TracTickets for help on using tickets.