Parse error using http.request() in node v0.4.1

[Charlie Robbins]

So in the process of updating node-http-proxy to work with node v0.4.1, I'm seeing some very strange behavior from instances of http.Agent. Namely, I keep seeing this all over the place:

{

  "message":"Parse Error",

  "bytesParsed":0

  "stack": [

    "Error: Parse Error",

    "at Socket.ondata (http.js:1183:22)",

    "at Socket._onReadable (net.js:654:27)"

    "IOWatcher.onReadable [as callback] (net.js:156:10)"

  ]

}

The really strange part about this is that I only see this when I run my entire test suite together. When I run an individual set of tests, they all pass with no problem. More info in a gist here: https://gist.github.com/836860 and the important commit to node-http-proxy are on the v0.4.0 branch: https://github.com/nodejitsu/node-http-proxy/commit/9faa924a29544cfd84c28cb1c45489f495e3806a

Basically, I just changed all references of p.request (where p is an instance of pool) to http.request. Seemed like it should be pretty straight forward then this popped up.

Has anyone seen this elsewhere in version v0.4.x?

--Charlie

[Julien Polo]

Yes I also got this bug when I upgraded to v0.4.1 I did not figure out
if it was a bug or an old silent error that nodejs detects now...

On 21 fév, 10:45, Charlie Robbins <charlie.robb...@gmail.com> wrote:
> So in the process of updating node-http-proxy to work with node v0.4.1, I'm
> seeing some very strange behavior from instances of http.Agent. Namely, I
> keep seeing this all over the place:
>
> {
>   "message":"Parse Error",
>   "bytesParsed":0
>   "stack": [
>     "Error: Parse Error",
>     "at Socket.ondata (http.js:1183:22)",
>     "at Socket._onReadable (net.js:654:27)"
>     "IOWatcher.onReadable [as callback] (net.js:156:10)"
>   ]
>
> }
>
> The really strange part about this is that I only see this when I run my
> entire test suite together. When I run an individual set of tests, they all

> pass with no problem. More info in a gist here:https://gist.github.com/836860and the important commit to node-http-proxy
> are on the v0.4.0 branch:https://github.com/nodejitsu/node-http-proxy/commit/9faa924a29544cfd8...

[Ryan Dahl]

Getting a tcpdump would help so we can determine if it's an actual
parse error or not.

[Julien Polo]

I've never used this tool before and my knowledge in low level network
is pretty thin. I tried with the "man tcpdump" but I was a little bit
lost I have to admit...


I can give you the code how I can reproduce it instead.

git clone git://github.com/as-jpolo/altshift.git

Then download and replace lib/altshift/http/client.js with this gist :
https://gist.github.com/847357

In the root of the package : "vows test/altshift/http/*.js" -> Parse
Error. I realized also that the tests are not failing if launched
separately...


Thanks,

On 24 fév, 20:20, Ryan Dahl <r...@tinyclouds.org> wrote:
> On Mon, Feb 21, 2011 at 1:45 AM, Charlie Robbins
>
>
>
>
>
>
>
>
>
> <charlie.robb...@gmail.com> wrote:
> > So in the process of updating node-http-proxy to work with node v0.4.1, I'm
> > seeing some very strange behavior from instances of http.Agent. Namely, I
> > keep seeing this all over the place:
> > {
> >   "message":"Parse Error",
> >   "bytesParsed":0
> >   "stack": [
> >     "Error: Parse Error",
> >     "at Socket.ondata (http.js:1183:22)",
> >     "at Socket._onReadable (net.js:654:27)"
> >     "IOWatcher.onReadable [as callback] (net.js:156:10)"
> >   ]
> > }
> > The really strange part about this is that I only see this when I run my
> > entire test suite together. When I run an individual set of tests, they all
> > pass with no problem. More info in a gist

> > here: https://gist.github.com/836860and the important commit to

> > node-http-proxy are on the v0.4.0

> > branch: https://github.com/nodejitsu/node-http-proxy/commit/9faa924a29544cfd8...

[Łukasz Mielicki]

Seems to break on the following response (don't mind it's an error response):

HTTP/1.1 500 Internal Server Error

Server: CouchDB/1.2.0a1072459 (Erlang OTP/R14B)

Date: Tue, 08 Mar 2011 19:28:52 GMT

Content-Type: text/plain;charset=utf-8

Content-Length: 90

Cache-Control: must-revalidate

{"error":"killed","reason":"{gen_server,call,[<0.848.0>,{pread_iolist,49316},infinity]}"}

Error: Parse Error

    at Socket.ondata (http.js:1186:22)

    at Socket._onReadable (net.js:654:27)

    at IOWatcher.onReadable [as callback] (net.js:156:10)

[Matt Ranney]

2011/3/8 Łukasz Mielicki <bo...@wp.pl>

Seems to break on the following response (don't mind it's an error response):

HTTP/1.1 500 Internal Server Error

Server: CouchDB/1.2.0a1072459 (Erlang OTP/R14B)

I get these parse error responses when talking to  CouchDB as well, but only under load.  I haven't been able to capture it in a repeatable way though.

Can you get it down to a single request that always gets a parse error?

[Łukasz Mielicki]

Nope. However I was getting this response quite often after decreasing _rev_limit. Thus I would not recommend changing that on production db.

[vicapow]

I am also getting this error with the following code:

sys = require('sys');
http = require('http');
fs = require('fs');

var url = {
all : 'http://i25.tinypic.com/2i8y73l.png'
};

var reqOpts = {
host : 'i25.tinypic.com',
path : '2i8y73l.png',
headers : {
'User-Agent' : 'ClickBin/0.1'
},
port : 80
};

var req = http.get(reqOpts, function(res) {
console.log('HEADERS: ' + JSON.stringify(res.headers));
filename = "../static/thumbnails/example.png";
console.log('thumbnail::addImageThumbnail(): start reading file');
var file = fs.createWriteStream(filename,{flags:'w',mode:0755});//
example file for now
assert.ok(file!=null);
res.on('data', function(chunk){
file.write(chunk);
console.log('thumbnail::addImageThumbnail(): on read data');
}).on('end', function(){
file.end();
console.log('thumbnail::addImageThumbnail(): done reading file');
}).on('error',function(err){
console.log('thumbnail::addImageThumbnail(): err on data write to
file');
sys.error(err.message);
});
});

[vicapow]

I've now come to realize, there was an error in my code. I should have
had preceded the path in my reqOpts with a forward slash '/'

now it works but the error i was getting was very confusing.

> On Mar 10, 4:21 am, £ukasz Mielicki <bo...@wp.pl> wrote:
>
>
>
>
>
>
>
> > On Thursday, March 10, 2011 5:00:45 AM UTC+1, mjr wrote:
>

> > > 2011/3/8 £ukasz Mielicki <bo...@wp.pl>

[Dominic Tarr]

I've caused parse errors by accidentially writing a string as the statusCode on my response.

this wasn't an intermittent problem, but it was a ParseError

--
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.

[Mikeal Rogers]

that's not true. all parse errors should emit on the HTTP Client object, which is the return value of the request call.

r = http.request(....)
r.on('error', function (e) {...})

[Julien Polo]

The bug is not reproduceable in node v0.4.3, I guess it was a nodejs
bug because my code didn't change at all...