No longer based on Ragel, but hand-written.
Had to add HTTPConnection.resetParser() because the parser is stricter and
will error out when you try to give it a message after the previous had
"Connection: close". The HTTP client was doing that. Thus we reset the
parser manually after each new connection.
This was modified in b893859c34 even though it
wasn't really required. Some users are experiencing problems after changing
to 1.0 - once those are identified the client will returned to 1.0.
Was sending two packets instead of one for some short messages, and even 3,
for short chunked-encoded messages. Also use the more general Encode()
function for receiving HTTP bodies.
Gives ~6% improvement on "hello world" web server benchmarks.
Instead of
myemitter.emit("event", [arg1, arg2, arg3]);
the API is now
myemitter.emit("event", arg1, arg2, arg3);
This change saves the creation of an extra array object for each event.
The implementation is also slightly more simple.
http://groups.google.com/group/nodejs/browse_thread/thread/16abfa87c32408f3
We have our node.js server monitored by monit, however it seems monit is pretty
agressive / quick about closing its connection and thus we've gotten into a
loop of errors like this:
at #<a ServerResponse>.flush
at #<a ServerResponse>.sendBody
at [object Object].json
at [object Object].[anonymous]
at [object Object].[anonymous]
at [object Object].[anonymous]
http.js:353: Socket is not open for writing
connection.send(out, out.encoding);
^
Below is a patch that basically cause flushMessageQueue to check the connection
state for each item in the queue rather than just a single time in the
beginning.
This is a rather large refactor! Mostly for the better side. I've had to
remove some functionality like req.interrupt(). A lot of other work is left
messy or incomplete.
The constructor for TCP servers can no longer take a connection handler for
purely technical reasons. (The constructor for EventEmitter is implemented
in C++ but addListener is in javascript, and I don't want to make too many
C++ -> Javascript references.) Thus I introduce new constructor methods to
ease the creation of the servers:
node.tcp.createServer()
node.http.createServer()
These work almost the same as the old constructors.
In general we're working towards a future where no constructors are
publicly exposed or take arguments.
The HTTP events like "on_uri" are not yet using the event interface.
onMessage still is a constructor - but this will change soon.