how can i reproduce this error

[Marak Squires]

Error: Parse Error

    at Client.ondata (http:899:22)

    at IOWatcher.callback (net:494:29)

    at node.js:764:9

I'm being told by our developers that this is a bug in core, I think it's an instance of http.Client missing an error handler (app is fairly complex, tracking down each instance isn't as easy as it should be). It's really annoying, takes down production servers about once a day.

Is this a known bug in core we are hitting? Any ideas how to reproduce this?

[Micheil Smith]

For what it's worth, I did see something quite similar to this the other day in the irc
channel; turned out to be a missing callback or bad variable.

Yours,
Micheil Smith
--
BrandedCode.com

> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[Marak Squires]

You'll see this happen if you don't put an error handler on http.Client and it throws an error. I think that MIGHT be the case here, but with a complex codebase and no way of reproducing the error, its hard to track down.

Is there a specific way to force a Parser error for the http.Client ?

[Ben Noordhuis]

On Sat, Sep 25, 2010 at 20:08, Marak Squires <marak....@gmail.com> wrote:
> Is there a specific way to force a Parser error for the http.Client ?

Feed it something that is not quite valid HTTP, e.g. chunked encoding
with bad chunk sizes.

[Marak Squires]

What tool would you recommend using to do this?

I wonder if there is a test that does this already in node's test suite? Is it possible that a request can be malformed in a specific way to break node's currently validation / error handling ?

--

[Ben Noordhuis]

> What tool would you recommend using to do this?

cat malformed-response.txt | nc -l localhost 8080

> I wonder if there is a test that does this already in node's test suite? Is
> it possible that a request can be malformed in a specific way to break
> node's currently validation / error handling ?

The HTTP parser is fail-fast, I think. In most cases it'll just throw
its hands up and raise an exception. There might be a browser hack or
two in there, though.

[Marak Squires]

Yeah, I'm a huge noob and have no idea what would go into "malformed-
response.txt", any additional pointers?

[Ben Noordhuis]

Look up chunked encoding. The file should contain the raw HTTP
response headers followed by a body that contains one or more chunks
where one has the wrong size.

I'd type out an example but I'm sending this from my phone. My tendons
are already protesting quietly. :)

[Marak Squires]

going to upgrade to 0.3.0 and see if this issue still happens. 

[Charlie Robbins]

Saw this error again today after upgrading to 0.3.0 . Will try to get
the headers / body of all incoming requests so that we can determine
where the parser is failing (if at all).

In the meantime, we're working around this thanks to 'forever'. Look
for an announcement later: http://github.com/indexzero/forever

Cheers,
Charlie

[r...@tinyclouds.org]

Try this:

client.on('data', function (d) {
console.log(d);
})

client.on('error', function (e) {
console.log("parse error at: %d', e.bytesParsed);
})

[Marak Squires]

ry -

we've been scratching our heads on this one, all client errors should have error handlers on them. we've been going back and forth with mikeal and think the issue is somewhere inside http://github.com/mikeal/node-utils/tree/master//pool/. 

i've got to assume its an integration bug somewhere where an instance of http.Client isn't being caught, but we really can't find it. i reverted back to a previous version of http-proxy that doesn't use pool and we aren't seeing the issue anymore.

i'll keep trying to track it down.... :-\

--

[r...@tinyclouds.org]

On Thu, Sep 30, 2010 at 11:56 AM, Marak Squires <marak....@gmail.com> wrote:
> ry -
> we've been scratching our heads on this one, all client errors should have
> error handlers on them. we've been going back and forth with mikeal and
> think the issue is somewhere
> inside http://github.com/mikeal/node-utils/tree/master//pool/.
> i've got to assume its an integration bug somewhere where an instance of
> http.Client isn't being caught, but we really can't find it. i reverted back
> to a previous version of http-proxy that doesn't use pool and we aren't
> seeing the issue anymore.
> i'll keep trying to track it down.... :-\

A good use-case for the long stack traces - hopefully I'll have that
landed in the next week.

[Marak Squires]

+50

:-)

--

[rmetzger]

Hi,

there is also a issue in the bug tracker concerning this:
http://github.com/ry/node/issues/issue/242 (and this discussion:
http://groups.google.com/group/nodejs/browse_thread/thread/e9ebb73ed64b52a3)
I've also this error running this code: http://gist.github.com/531588

Thats my output using client.on('error', function (e)
{ console.log("parse error at: %d', e.bytesParsed); ...
$ node bug.js
<Buffer 48 54 54 50 2f 31 2e 31 20 33 30 32 20 46 6f 75 6e 64 0d 0a 41
67 65 3a 20 32 31 31 33 20 20 20 20 20 20 0d 0a 44 61 74 65 3a 20 54
75 65 2c 20 30 35 20 4f 63 74 20 32 30 31 30 20 31 33 3a 32 38 3a 35
30 20 47 4d 54 0d 0a 45 78 70 69 72 65 73 3a 20 54 75 65 2c 20 30 35
20 4f 63 74 20 32 30 31 30 20 31 33 3a 34 38 3a 35 30 20 47 4d 54 0d
0a 43 61 63 68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 6d 61 78 2d 61 67 65
3d 31 32 30 30 20 20 20 20 20 20 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65
6e 67 74 68 3a 20 30 20 20 20 20 20 20 20 20 20 0d 0a 43 6f 6e 6e 65
63 74 69 6f 6e 3a 20 4b 65 65 70 2d 41 6c 69 76 65 0d 0a 56 69 61 3a
20 4e 53 2d 43 41 43 48 45 2d 36 2e 31 3a 20 20 33 36 0d 0a 53 65 72
76 65 72 3a 20 41 70 61 63 68 65 2f 31 2e 33 2e 34 31 20 28 44 61 72
77 69 6e 29 20 50 48 50 2f 34 2e 34 2e 39 0d 0a 58 2d 50 6f 77 65 72
65 64 2d 42 79 3a 20 50 48 50 2f 34 2e 34 2e 39 0d 0a 53 74 61 74 75
73 3a 20 33 30 32 20 4d 6f 76 65 64 20 54 65 6d 70 6f 72 61 72 69 6c
79 0d 0a 4c 6f 63 61 74 69 6f 6e 3a 20 68 74 74 70 3a 2f 2f 77 77 77
2e 67 72 75 6e 67 65 66 6d 2e 63 6f 6d 2f 69 74 75 6e 65 73 2f 31 30
30 33 48 49 2e 70 6c 73 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a
20 74 65 78 74 2f 68 74 6d 6c 0d 0a 0d 0a>
parse error at: 166

The converted response seems to be valid...

On 30 Sep., 21:17, Marak Squires <marak.squi...@gmail.com> wrote:
> +50
>
> :-)
>
>
>
> On Thu, Sep 30, 2010 at 3:12 PM, <r...@tinyclouds.org> wrote:

> > On Thu, Sep 30, 2010 at 11:56 AM, Marak Squires <marak.squi...@gmail.com>

> > wrote:
> > > ry -
> > > we've been scratching our heads on this one, all client errors should
> > have
> > > error handlers on them. we've been going back and forth with mikeal and
> > > think the issue is somewhere

> > > insidehttp://github.com/mikeal/node-utils/tree/master//pool/.

> > > i've got to assume its an integration bug somewhere where an instance of
> > > http.Client isn't being caught, but we really can't find it. i reverted
> > back
> > > to a previous version of http-proxy that doesn't use pool and we aren't
> > > seeing the issue anymore.
> > > i'll keep trying to track it down.... :-\
>
> > A good use-case for the long stack traces - hopefully I'll have that
> > landed in the next week.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > .