Ssotomayor feature/532 content type hard not send

[jonathanong]

closes #532
closes #534

@dougwilson @fundon @ssotomayor how about this?

[ssotomayor]

Seems in the same direction as this, however as i pointed out before, i'm not sure why is application/octet-stream as the default option, there are even tests checking that. If there is no logical reason i support the option of setting null as any header option to NOT send it, then the user decides.

[fundon]

LGTM

[jonathanong]

anyone else?

[tejasmanohar]

LGTM. agree w/ @dougwilson's comment on the previous PR for this fix

[juliangruber]

+1

[fengmk2]

+1

[dougwilson]

LGTM

[tj]

@ssotomayor octet stream is a reasonable default I think, everything is an octet stream haha, but 👍 for being able to unset

[ssotomayor]

Just closed the other PR, i agree with the fixes. 👍

[evilive3000]

Hi. Is there a way to respond with an undefined body and DO NOT set a content-type.

I'm trying to make an internal redirect by nginx depend on the headers that returned from koa's backend. All I need is only one field X-Accel-Redirect; but Koa appends Content-Type: text/plain header which will be transparently proxied through nginx. But if content-type were absent in koa's respond Nginx automatically decides what type it is and sets it correctly.

I found the code where the magic happens application.js#L218:

  // status body
  if (null == body) {
    body = ctx.message || String(code);
    if (!res.headersSent) {
      ctx.type = 'text';
      ctx.length = Buffer.byteLength(body);
    }
    return res.end(body);
  }

according to this I will always get non empty body?

[evilive3000]

Right after posting prev comment I found that if I explicitly set body to null ctx.body = null; I receive 204 status code as expected. Wonder why it is not default behavior. When I don't set the body shouldn't it be treated as if I set it to null