librelist archives

Re: [mongrel2] json parser bug?

From:

snacktime

Date:

2010-09-30 @ 23:06

On Thu, Sep 30, 2010 at 4:02 PM, snacktime <snacktime@gmail.com> wrote:
> Here is the debug output.  Notice the message length of 1072, which
> has got to be the size of all those messages that got sent as one to
> the handler.
>
>
>
> DEBUG src/host.c:127: Found backend at @chat
> DEBUG src/connection.c:159: --> msg_to_handler(HANDLER:106)
> connection_msg_to_handler:159
> DEBUG src/connection.c:181: MSG TO HANDLER:
> 54c6755b-9628-40a4-9a2d-cc82a816345e 0 @chat
> 
50:{"PATH":"@chat","METHOD":"JSON","PATTERN":"@chat"},1072:{"id":159,"createdAt":1691504774,"data":{"test2":[1,2,3,4,5],"test":"test"}}
>
>
> Chris


And here is what I logged as what the ruby handler got from mongrel2
for the body.  Note the first message in the clump is 159.


"{\"id\":159,\"createdAt\":1691504774,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}\x00@chat

{\"id\":160,\"createdAt\":1691504934,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}\x00@chat

{\"id\":161,\"createdAt\":1691505062,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}\x00@chat

{\"id\":162,\"createdAt\":1691505206,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}\x00@chat

{\"id\":163,\"createdAt\":1691505342,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}\x00@chat

{\"id\":164,\"createdAt\":1691505478,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}\x00@chat

{\"id\":165,\"createdAt\":1691505589,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}\x00@chat

{\"id\":166,\"createdAt\":1691505718,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}\x00@chat

{\"id\":167,\"createdAt\":1691505878,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}\x00@chat

{\"id\":168,\"createdAt\":1691506038,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}\x00@chat

{\"id\":169,\"createdAt\":1691506170,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}\x00@chat

{\"id\":170,\"createdAt\":1691506310,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}\x00@chat

{\"id\":171,\"createdAt\":1691506446,\"data\":{\"test2\":[1,2,3,4,5],\"test\":\"test\"}}"

On Thu, Sep 30, 2010 at 04:06:48PM -0700, snacktime wrote:
> On Thu, Sep 30, 2010 at 4:02 PM, snacktime <snacktime@gmail.com> wrote:
> > Here is the debug output.  Notice the message length of 1072, which
> > has got to be the size of all those messages that got sent as one to
> > the handler.

Cool, ok I just added changes to the fossil that should fix this, add
xml, and give you a Handler.raw_payload optional setting.  Set it to 1
and that payload will not get the base64 treatment.

Try out your test here to make sure what I did works.  I wrote a test
file tests/and_suite/json_socket_tests and made sure that it parsed each
message separately including mixed in xml.  It *should* work but we
might need to work up a new test file.

Last thing, I'm still doing the @blah prefix for xml, so a valid message
is:

@chat <some><xml></xml></some>\0

Not sure if that will work with the socket stuff, so an idea I had, and
this could be really cool, is let the prefix be any one single xml
element, like:

<chat/><some><xml></xml></some>\0

Let me know what you think of that idea, since that could be used to
normalize the flash security stuff too.  You'd then set your route to
be:

  '<chat/>': xml_handler

If you wanted that.


-- 
Zed A. Shaw
http://zedshaw.com/

On Thu, Sep 30, 2010 at 5:43 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> On Thu, Sep 30, 2010 at 04:06:48PM -0700, snacktime wrote:
>> On Thu, Sep 30, 2010 at 4:02 PM, snacktime <snacktime@gmail.com> wrote:
>> > Here is the debug output.  Notice the message length of 1072, which
>> > has got to be the size of all those messages that got sent as one to
>> > the handler.
>
> Cool, ok I just added changes to the fossil that should fix this, add
> xml, and give you a Handler.raw_payload optional setting.  Set it to 1
> and that payload will not get the base64 treatment.
>
> Try out your test here to make sure what I did works.  I wrote a test
> file tests/and_suite/json_socket_tests and made sure that it parsed each
> message separately including mixed in xml.  It *should* work but we
> might need to work up a new test file.

Ok testing it out now.  I don't see a nul terminator on the messages
sent back to the client now.

Chris

On Fri, Oct 01, 2010 at 10:50:12AM -0700, snacktime wrote:
> On Thu, Sep 30, 2010 at 5:43 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> > Try out your test here to make sure what I did works.  I wrote a test
> > file tests/and_suite/json_socket_tests and made sure that it parsed each
> > message separately including mixed in xml.  It *should* work but we
> > might need to work up a new test file.
> 
> Ok testing it out now.  I don't see a nul terminator on the messages
> sent back to the client now.

Uh, does that mean it worked?

-- 
Zed A. Shaw
http://zedshaw.com/

On Fri, Oct 1, 2010 at 11:17 AM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> On Fri, Oct 01, 2010 at 10:50:12AM -0700, snacktime wrote:
>> On Thu, Sep 30, 2010 at 5:43 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
>> > Try out your test here to make sure what I did works.  I wrote a test
>> > file tests/and_suite/json_socket_tests and made sure that it parsed each
>> > message separately including mixed in xml.  It *should* work but we
>> > might need to work up a new test file.
>>
>> Ok testing it out now.  I don't see a nul terminator on the messages
>> sent back to the client now.
>
> Uh, does that mean it worked?
>

It doesn't work.  Previously all messages sent back to the client were
terminated with "\0" by mongrel2, now they are not from what I can
tell.

I also just tested sending a bunch of messages at the same time, and
I'm seeing the same parsing problem.  The handler is getting all the
messages as one message.

The base64 option works.

Chris


> --
> Zed A. Shaw
> http://zedshaw.com/
>

Alright, if you fossil up you can get my quick and dirty fix for this.
I really have to redesign how buffers are being used, but this will get
it working for you for today.  Try it out and let me know what you get.

My little test script that blasts 100 xml messages works, json msgs
work, and http keeps working.  Hopefully that means it's working minus a
few edge cases.

-- 
Zed A. Shaw
http://zedshaw.com/

On Fri, Oct 1, 2010 at 1:14 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> Alright, if you fossil up you can get my quick and dirty fix for this.
> I really have to redesign how buffers are being used, but this will get
> it working for you for today.  Try it out and let me know what you get.
>
> My little test script that blasts 100 xml messages works, json msgs
> work, and http keeps working.  Hopefully that means it's working minus a
> few edge cases.

Hey fast turnaround on that thanks!  Still have that one new bug.
Messages sent back to the client are missing the "\0" terminator.

Chris

On Fri, Oct 01, 2010 at 01:31:31PM -0700, snacktime wrote:
> On Fri, Oct 1, 2010 at 1:14 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> > Alright, if you fossil up you can get my quick and dirty fix for this.
> > I really have to redesign how buffers are being used, but this will get
> > it working for you for today.  Try it out and let me know what you get.
> >
> > My little test script that blasts 100 xml messages works, json msgs
> > work, and http keeps working.  Hopefully that means it's working minus a
> > few edge cases.
> 
> Hey fast turnaround on that thanks!  Still have that one new bug.
> Messages sent back to the client are missing the "\0" terminator.

Your handler should be adding a \0, is it not?

-- 
Zed A. Shaw
http://zedshaw.com/

On Fri, Oct 1, 2010 at 2:26 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> On Fri, Oct 01, 2010 at 01:31:31PM -0700, snacktime wrote:
>> On Fri, Oct 1, 2010 at 1:14 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
>> > Alright, if you fossil up you can get my quick and dirty fix for this.
>> > I really have to redesign how buffers are being used, but this will get
>> > it working for you for today.  Try it out and let me know what you get.
>> >
>> > My little test script that blasts 100 xml messages works, json msgs
>> > work, and http keeps working.  Hopefully that means it's working minus a
>> > few edge cases.
>>
>> Hey fast turnaround on that thanks!  Still have that one new bug.
>> Messages sent back to the client are missing the "\0" terminator.
>
> Your handler should be adding a \0, is it not?

See the message after this one for what's happening.  The handler
doesn't add \0, the server does (or did).

Chris

On Fri, Oct 01, 2010 at 02:34:31PM -0700, snacktime wrote:
> See the message after this one for what's happening.  The handler
> doesn't add \0, the server does (or did).

Right, my handlers do though, so have your handlers add one if you're
doing a raw socket.

Here's why:  a b64 socket is considered a single message, so mongrel2
can compensate for badly written handlers that don't add a \0.  A raw
socket however is exactly what it says, raw.  It has no idea if you are
streaming a file, sending http, headers, a body, nothing.  That means
you have to add the \0 yourself otherwise it'd be adding \0 to random
points in a message stream.

-- 
Zed A. Shaw
http://zedshaw.com/

On Fri, Oct 1, 2010 at 2:37 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> On Fri, Oct 01, 2010 at 02:34:31PM -0700, snacktime wrote:
>> See the message after this one for what's happening.  The handler
>> doesn't add \0, the server does (or did).
>
> Right, my handlers do though, so have your handlers add one if you're
> doing a raw socket.
>
> Here's why:  a b64 socket is considered a single message, so mongrel2
> can compensate for badly written handlers that don't add a \0.  A raw
> socket however is exactly what it says, raw.  It has no idea if you are
> streaming a file, sending http, headers, a body, nothing.  That means
> you have to add the \0 yourself otherwise it'd be adding \0 to random
> points in a message stream.
>

Seems strange at first to have a different data format for each
direction, but it is more flexible I kind of like it.

Chris

On Fri, Oct 01, 2010 at 02:59:48PM -0700, snacktime wrote:
> Seems strange at first to have a different data format for each
> direction, but it is more flexible I kind of like it.

Well, keep in mind it is the base that supports http, json streams, xml
streams, whatever.  Rather than assume what you're going to send, it'll
just let you send what you need.

Anyway, stay tuned, I think tomorrow I'll have this buffering stuff all
cleaned up.  It's kind of a mess right now.

-- 
Zed A. Shaw
http://zedshaw.com/

On Fri, Oct 1, 2010 at 1:31 PM, snacktime <snacktime@gmail.com> wrote:
> On Fri, Oct 1, 2010 at 1:14 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
>> Alright, if you fossil up you can get my quick and dirty fix for this.
>> I really have to redesign how buffers are being used, but this will get
>> it working for you for today.  Try it out and let me know what you get.
>>
>> My little test script that blasts 100 xml messages works, json msgs
>> work, and http keeps working.  Hopefully that means it's working minus a
>> few edge cases.
>
> Hey fast turnaround on that thanks!  Still have that one new bug.
> Messages sent back to the client are missing the "\0" terminator.
>
> Chris
>

I see it.  fdsend in Connection_deliver adds 1 to the length of the
data which I assume adds the nul character at the end.
Connection_deliver_raw does not, and when not base64 encoding data is
send using Connection_deliver_raw.

Chris

I'm seeing something really strange and can't yet find a pattern to
it.  I can't completely rule out the client, but I'm logging the raw
data sent right when I write to the socket, so I'm fairly sure..

I'm sending a batch of 50 messages at once, each with sequential id's
1-50.  At random, the handler will get two of one message with the
same id, and there will be a corresponding missing message.  For
example it gets message 49 twice but never gets 50.   Seems to happen
around 5%-10% of the time.  Really strange.

Chris

On Fri, Oct 1, 2010 at 2:14 PM, snacktime <snacktime@gmail.com> wrote:
> I'm seeing something really strange and can't yet find a pattern to
> it.  I can't completely rule out the client, but I'm logging the raw
> data sent right when I write to the socket, so I'm fairly sure..
>
> I'm sending a batch of 50 messages at once, each with sequential id's
> 1-50.  At random, the handler will get two of one message with the
> same id, and there will be a corresponding missing message.  For
> example it gets message 49 twice but never gets 50.   Seems to happen
> around 5%-10% of the time.  Really strange.
>
> Chris
>

It's happening when there are multiple messages in the buffer to
parse.  In the logs it's always the last two messages before you see
OUT OF DATA.  This is one example, the rest follow th same pattern.
It shows two json messages with an id of 6, then OUT OF DATA, then
shows a message with an id of 8.   It ate number 7 !!


DEBUG src/connection.c:189: MSG nread: 243, nparsed: 81
DEBUG src/connection.c:196: NEW MSG: @chat
{"id":6,"createdAt":1771604434,"data":{"test2":[1,2,3,4,5],"test":"test"}}
DEBUG src/connection.c:654: --> identify_request(REQ_RECV:112)
connection_identify_request:654
DEBUG src/connection.c:625: JSON REQUEST:
{"id":6,"createdAt":1771604434,"data":{"test2":[1,2,3,4,5],"test":"test"}}
DEBUG src/connection.c:128: --> route(MSG_REQ:108) connection_route_request:128
DEBUG src/routing.c:205: Found simple prefix: @chat
DEBUG src/host.c:127: Found backend at @chat
DEBUG src/connection.c:159: --> msg_to_handler(HANDLER:106)
connection_msg_to_handler:159
DEBUG src/connection.c:180: MSG TO HANDLER:
54c6755b-9628-40a4-9a2d-cc82a816345e 8 @chat

84:{"PATH":"@chat","METHOD":"JSON","PATTERN":"@chat","X-Forwarded-For":"192.168.234.1"},74:{"id":6,"createdAt":1771604434,"data":{"test2":[1,2,3,4,5],"test":"test"}},
of LENGTH: 211
DEBUG src/connection.c:189: MSG nread: 162, nparsed: 81
DEBUG src/connection.c:196: NEW MSG: @chat
{"id":6,"createdAt":1771604434,"data":{"test2":[1,2,3,4,5],"test":"test"}}
DEBUG src/connection.c:654: --> identify_request(REQ_RECV:112)
connection_identify_request:654
DEBUG src/connection.c:625: JSON REQUEST:
{"id":6,"createdAt":1771604434,"data":{"test2":[1,2,3,4,5],"test":"test"}}
DEBUG src/connection.c:128: --> route(MSG_REQ:108) connection_route_request:128
DEBUG src/routing.c:205: Found simple prefix: @chat
DEBUG src/host.c:127: Found backend at @chat
DEBUG src/connection.c:159: --> msg_to_handler(HANDLER:106)
connection_msg_to_handler:159
DEBUG src/connection.c:180: MSG TO HANDLER:
54c6755b-9628-40a4-9a2d-cc82a816345e 8 @chat

84:{"PATH":"@chat","METHOD":"JSON","PATTERN":"@chat","X-Forwarded-For":"192.168.234.1"},74:{"id":6,"createdAt":1771604434,"data":{"test2":[1,2,3,4,5],"test":"test"}},
of LENGTH: 211
DEBUG src/connection.c:189: MSG nread: 81, nparsed: 81
DEBUG src/connection.c:198: OUT OF DATA
DEBUG src/connection.c:654: --> identify_request(REQ_RECV:112)
connection_identify_request:654
DEBUG src/connection.c:625: JSON REQUEST:
{"id":8,"createdAt":1771604435,"data":{"test2":[1,2,3,4,5],"test":"test"}}
DEBUG src/connection.c:128: --> route(MSG_REQ:108) connection_route_request:128
DEBUG src/routing.c:205: Found simple prefix: @chat
DEBUG src/host.c:127: Found backend at @chat
DEBUG src/connection.c:159: --> msg_to_handler(HANDLER:106)
connection_msg_to_handler:159
DEBUG src/connection.c:180: MSG TO HANDLER:
54c6755b-9628-40a4-9a2d-cc82a816345e 8 @chat

84:{"PATH":"@chat","METHOD":"JSON","PATTERN":"@chat","X-Forwarded-For":"192.168.234.1"},74:{"id":8,"createdAt":1771604435,"data":{"test2":[1,2,3,4,5],"test":"test"}},
of LENGTH: 211

On Fri, Oct 01, 2010 at 02:25:56PM -0700, snacktime wrote:
> On Fri, Oct 1, 2010 at 2:14 PM, snacktime <snacktime@gmail.com> wrote:
> > I'm seeing something really strange and can't yet find a pattern to
> > it.  I can't completely rule out the client, but I'm logging the raw
> > data sent right when I write to the socket, so I'm fairly sure..
> >
> > I'm sending a batch of 50 messages at once, each with sequential id's
> > 1-50.  At random, the handler will get two of one message with the
> > same id, and there will be a corresponding missing message.  For
> > example it gets message 49 twice but never gets 50.   Seems to happen
> > around 5%-10% of the time.  Really strange.
> >
> > Chris
> >
> 
> It's happening when there are multiple messages in the buffer to
> parse.  In the logs it's always the last two messages before you see
> OUT OF DATA.  This is one example, the rest follow th same pattern.
> It shows two json messages with an id of 6, then OUT OF DATA, then
> shows a message with an id of 8.   It ate number 7 !!

Well I'll take a look, might be one of the edge cases I'm talking about.

Incidentally, can you write a simplied test case like I did that makes
this happen and attach it?  That'd save me a ton of time tracking it
down.

-- 
Zed A. Shaw
http://zedshaw.com/

On Fri, Oct 1, 2010 at 2:30 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> On Fri, Oct 01, 2010 at 02:25:56PM -0700, snacktime wrote:
>> On Fri, Oct 1, 2010 at 2:14 PM, snacktime <snacktime@gmail.com> wrote:
>> > I'm seeing something really strange and can't yet find a pattern to
>> > it.  I can't completely rule out the client, but I'm logging the raw
>> > data sent right when I write to the socket, so I'm fairly sure..
>> >
>> > I'm sending a batch of 50 messages at once, each with sequential id's
>> > 1-50.  At random, the handler will get two of one message with the
>> > same id, and there will be a corresponding missing message.  For
>> > example it gets message 49 twice but never gets 50.   Seems to happen
>> > around 5%-10% of the time.  Really strange.
>> >
>> > Chris
>> >
>>
>> It's happening when there are multiple messages in the buffer to
>> parse.  In the logs it's always the last two messages before you see
>> OUT OF DATA.  This is one example, the rest follow th same pattern.
>> It shows two json messages with an id of 6, then OUT OF DATA, then
>> shows a message with an id of 8.   It ate number 7 !!
>
> Well I'll take a look, might be one of the edge cases I'm talking about.
>
> Incidentally, can you write a simplied test case like I did that makes
> this happen and attach it?  That'd save me a ton of time tracking it
> down.

http://dpaste.de/r4x0/

Chris

On Fri, Oct 01, 2010 at 03:38:46PM -0700, snacktime wrote:
> > Incidentally, can you write a simplied test case like I did that makes
> > this happen and attach it?  That'd save me a ton of time tracking it
> > down.
> 
> http://dpaste.de/r4x0/

This doesn't work, and actually can't be working at all unless you
hacked the parser.  Json message start with a @blah route.  I'm going to
add that in and try to get it to replicate your error, but maybe
recompile with the source fresh to make sure you don't have some hack
you did in there.

-- 
Zed A. Shaw
http://zedshaw.com/

On Fri, Oct 1, 2010 at 6:32 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> On Fri, Oct 01, 2010 at 03:38:46PM -0700, snacktime wrote:
>> > Incidentally, can you write a simplied test case like I did that makes
>> > this happen and attach it?  That'd save me a ton of time tracking it
>> > down.
>>
>> http://dpaste.de/r4x0/
>
> This doesn't work, and actually can't be working at all unless you
> hacked the parser.  Json message start with a @blah route.  I'm going to
> add that in and try to get it to replicate your error, but maybe
> recompile with the source fresh to make sure you don't have some hack
> you did in there.
>
> --
> Zed A. Shaw
> http://zedshaw.com/
>
So that was a whole 3 days ago, and I'm not sure if that was a typo or
that's what I actually ran.  It's obviously not correct.

In any case I'll just wait until you have stuff refactored rather then
keep trying to test/break stuff that's going to change anyways.

Chris

Another bug that I think is related to the duplicate messages.  After
the duplicate message thing happens, the server can hang using up 100%
of the cpu when sending it more messages (doesn't always happens).  I
have to kill -9 it, even after disconnecting client and handler.  The
last line in the log is the NEW MSG line.

Seeing if I can get a reliable test case.

Chris

On Fri, Oct 01, 2010 at 03:56:19PM -0700, snacktime wrote:
> Another bug that I think is related to the duplicate messages.  After
> the duplicate message thing happens, the server can hang using up 100%
> of the cpu when sending it more messages (doesn't always happens).  I
> have to kill -9 it, even after disconnecting client and handler.  The
> last line in the log is the NEW MSG line.

Cool, like I said this was a quick and dirty fix, but now I shall make
it clean and nice.

-- 
Zed A. Shaw
http://zedshaw.com/

>> It's happening when there are multiple messages in the buffer to
>> parse.  In the logs it's always the last two messages before you see
>> OUT OF DATA.  This is one example, the rest follow th same pattern.
>> It shows two json messages with an id of 6, then OUT OF DATA, then
>> shows a message with an id of 8.   It ate number 7 !!
>
> Well I'll take a look, might be one of the edge cases I'm talking about.
>
> Incidentally, can you write a simplied test case like I did that makes
> this happen and attach it?  That'd save me a ton of time tracking it
> down.
>

Ya no problem.

Chris

On Fri, Oct 01, 2010 at 11:23:43AM -0700, snacktime wrote:
> I also just tested sending a bunch of messages at the same time, and
> I'm seeing the same parsing problem.  The handler is getting all the
> messages as one message.

Annnnnd, I see what's going on.  Alright I should have this fixed today.
What happened is I was using the amount read not parsed when I crafted
the payload for MSG requests.  That and I'm not trying to read as many
requests as I can off of one buffer read.

I'll fix this up today probably and let you know.

-- 
Zed A. Shaw
http://zedshaw.com/

On Fri, Oct 01, 2010 at 11:23:43AM -0700, snacktime wrote:
> It doesn't work.  Previously all messages sent back to the client were
> terminated with "\0" by mongrel2, now they are not from what I can
> tell.

http://dpaste.de/HN2J/

Got it, this causes the bug so now I can fix it.

-- 
Zed A. Shaw
http://zedshaw.com/

On Fri, Oct 01, 2010 at 11:23:43AM -0700, snacktime wrote:
> It doesn't work.  Previously all messages sent back to the client were
> terminated with "\0" by mongrel2, now they are not from what I can
> tell.
> 
> I also just tested sending a bunch of messages at the same time, and
> I'm seeing the same parsing problem.  The handler is getting all the
> messages as one message.

Well what the hell?  I mean I have a file with a blob of random messages
all together, so why would it be dropping the \0 at all?  I mean it
would either parse it and include it, or error out, but not remove it.

I'm thinking it's not in the parser, but in the payload generation.
I'll debug there.

In the meantime, I got the XML socket stuff working.  Can you test that
out?  It's really simple, create a route for <TAGNAME that's your root
tag.  Then point that route at a handler like normal.  The handler then
will get <TAGNAME as the PATH, XML as the METHOD, and the whole message
up to the \0 as the body.

Try it and let me know if it works.  It'll probably still have the same
bug as you currently have though.

-- 
Zed A. Shaw
http://zedshaw.com/

On Thu, Sep 30, 2010 at 5:43 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> On Thu, Sep 30, 2010 at 04:06:48PM -0700, snacktime wrote:
>> On Thu, Sep 30, 2010 at 4:02 PM, snacktime <snacktime@gmail.com> wrote:
>> > Here is the debug output.  Notice the message length of 1072, which
>> > has got to be the size of all those messages that got sent as one to
>> > the handler.
>
> Cool, ok I just added changes to the fossil that should fix this, add
> xml, and give you a Handler.raw_payload optional setting.  Set it to 1
> and that payload will not get the base64 treatment.
>
> Try out your test here to make sure what I did works.  I wrote a test
> file tests/and_suite/json_socket_tests and made sure that it parsed each
> message separately including mixed in xml.  It *should* work but we
> might need to work up a new test file.
>
> Last thing, I'm still doing the @blah prefix for xml, so a valid message
> is:
>
> @chat <some><xml></xml></some>\0
>
> Not sure if that will work with the socket stuff, so an idea I had, and
> this could be really cool, is let the prefix be any one single xml
> element, like:
>
> <chat/><some><xml></xml></some>\0
>
> Let me know what you think of that idea, since that could be used to
> normalize the flash security stuff too.  You'd then set your route to
> be:
>
>  '<chat/>': xml_handler
>
> If you wanted that.
>

Very cool.  At first thought I like the idea of using xml for the
prefix for xml messages.

Btw, the fossil package that comes with the latest ubuntu doesn't
work, I get 'fossil: cannot locate "latest" checkout' with fossil
open.  The binary from the fossil website works fine.

Chris

>
> --
> Zed A. Shaw
> http://zedshaw.com/
>

On Thu, Sep 30, 2010 at 06:17:12PM -0700, snacktime wrote:
> Btw, the fossil package that comes with the latest ubuntu doesn't
> work, I get 'fossil: cannot locate "latest" checkout' with fossil
> open.  The binary from the fossil website works fine.

Don't use that. Man I *hate* Debian.  They could screw up a wet dream.

Just download the static binary from fossil-scm.org.

-- 
Zed A. Shaw
http://zedshaw.com/

Hi guys,
I'd like to translate the manual to Chinese but I don't know where to start,
can you give me some introductions?

Thanks,
F. Zhang