connect server throws runtime SyntaxError if content-length is less than actual length #889

gdbtek opened this Issue Sep 9, 2013 · 15 comments


None yet
4 participants

gdbtek commented Sep 9, 2013

I logged this issue on express.js but it looks like connect's issue.

Steps to reproduce using latest version of express 3.3.8 on npm

  1. I created a sample express using comamnd: express myapp. Note that I did not change anything after express generate the template app.
  2. Write simple app to test rest api. Note that data.firstName contains non-ascii char.
// test.js

var http = require('http');

var data = JSON.stringify({
  firstName: 'JoaquÌn',    // <<<<<<<<<<<<<< 

var options = {
  host: '',
  port: 3000,
  path: '/users',
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Content-Length': data.length    // <<<<<<<<<<

var req = http.request(options, function(res) {
  var result = '';

  res.on('data', function(chunk) {
    result += chunk;

  res.on('end', function() {

req.on('error', function(err) {


  1. run the


$ mnode app.js
Express server listening on port 3000
SyntaxError: Unexpected end of input
    at Object.parse (native)
    at IncomingMessage.<anonymous> (/Volumes/Data/Junk/myapp/node_modules/express/node_modules/connect/lib/middleware/json.js:76:27)
    at IncomingMessage.EventEmitter.emit (events.js:92:17)
    at _stream_readable.js:920:16
    at process._tickCallback (node.js:415:13)
POST /users 400 7ms

connect lib should handle errors gracefully

Work Around:
use 'Content-Length': Buffer.byteLength(data) instead of data.length


jonathanong commented Sep 9, 2013

This isn't a connect or express issue so it's not appropriate for either. It's actually a node/http "issue", and by "issue" I mean something you just have to learn. Content length means byte length, not string length. Those special letters are more than one byte each (I don't know why).

Node does document this I think, but it hard for beginners to learn. It's in the Buffer documentation somewhere (I would link you but I'm on my phone). Really the best thing to do is make a blog post with "all of node's quirks".


jonathanong commented Sep 9, 2013

It would be an issue if the error wasn't caught, but in this case it's caught. What do you suggest for improvements?


JacksonTian commented Sep 10, 2013

Yes, byte length, not string length. Just ascii char is 1 byte.

gdbtek commented Sep 10, 2013

@jonathanong there are many posts and samples out there using .length instead of .byteLength. The good thing is this error throws and did not crash express/connect server. So I think if we have a blog or document showing to catch up is good enough for now.

gdbtek commented Sep 10, 2013

actually this issue is not about ascii or non asscii data, it's all about content-length. As long as content-length is less than the actual length, the server will throw errors. I tested it.


jonathanong commented Sep 10, 2013

yup. you should call them all out! now that i'm at the computer, here's a link:

i don't have a blog (that anybody reads, yet). you can start a blog with your experience with node - people would want that, especially the node masters so they can understand the difficult parts.

it should throw if the content-length is incorrect - it's invalid.

gdbtek commented Sep 10, 2013

shall we close this issue?


jonathanong commented Sep 10, 2013

i think so.

gdbtek commented Sep 10, 2013

alright, CLOSE it! Thanks @jonathanong and @JacksonTian

@gdbtek gdbtek closed this Sep 10, 2013

Guys, this issue should be reopened. This isn't about content-length vs byte length in server code. This is an exploit that a third party can launch against the server, and there's no way to test for this specific exploit and handle it appropriately in application code, because it's not possible to distinguish it from other types of random errors.

We need the opportunity to test for this specific error and respond with a 500 error instead of shutting down so that it can't be exploited as a DOS attack.

gdbtek commented Sep 12, 2013

@dilvie glad that you agree. I will reopen this issue so we can have a second look.

@gdbtek gdbtek reopened this Sep 12, 2013


jonathanong commented Sep 12, 2013

it does not throw the error. it handles and passes the error. the server is not shut down and no DoS attack is possible. it is not a 500 error. it is a 400 error, which connect sends correctly.

now if the error crashes the server, that is an issue, but that's just not the case. the process does not exit in his code sample.

on the other hand, i agree that connect should be more strict with the data. it should make sure the received request matches the content length header and throw a specific error otherwise. however, this is not a security issue, just telling the client what exactly they're doing wrong. this middleware will work well without it.

I am working on a library that would solve this issue, but it's not node v0.8 compatible, otherwise i would submit a pull request:

@jonathanong Yeah! I see it now that I'm looking at the connect source code, and I am able to test for the 400 and deliver a 400 response. That satisfies me on this issue, I think. Thanks for following up! =)


jonathanong commented Sep 13, 2013

i'm closing this issue because the premise is not quite correct (it is thrown, but caught and handled appropriately). however, you may want to open a new issue titled "better errors when content length is incorrect" or something.

gdbtek commented Sep 13, 2013

@jonathanong sounds good to me. will open a new issue and will reference this issue. Thanks @jonathanong

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment