* Use node 7+ WHATWG parser for hostname, fixes#1002
* only use URL if host is IPv6, expose parsed URL
* catch invalid URLs, memoize empty obj
* hostname returns empty string when URL throws
* Don't use http.ServerResponse._header when accessors exist
Structure of http.ServerResponse._header will change in future
Node versions. Avoid reading and setting it directly when
helpers exist.
* Add new header test case
* make things a little more strict
change var to const for static require()'d modules
make constant var references in app use const keyword
refactor context to use es6 constants
refactor request to use es6 constants, let block-scope coming next
use const in response object for static refs
make context tests use es6 constants
experimental unit tests -> const
use const for static references in unit test over req
use const for static refs in res tests
update app tests to use const for static refs
make the context test use es6 constants for static refs
use constants in the README
es6 constants seem to work in --harmony on 0.12 too
use const's for immutable refs in benchmarks
ensure all JS files have blank newline at top
add newline to bottom of file where missing
add a webchat freenode link to irc channel
no need to assign error in catch{}-able test
app.silent option to turn off err logging
keep test env logging for backwards-compat
When calling `ctx.throw`, you're allowed to provide an error object and a
status code. The status code is later set as the `status` property of the error
object. If no status code is provided, it defaults to 500. However, this
happens even if the error object already had a `status` property.
This commit allows an error's pre-existing `status` property to be used in
conjunction with `ctx.throw`.
If the status code is below 500, the error message will be exposed to the user
in the HTTP response. It would be nice to have some Error subclasses that
always have the same status code, because then we could just write
`ctx.throw(new WhateverError())`, and define which 4xx error code we want in
the definition of `WhateverError` itself. If, for example, an
`AuthenticationError` is always meant to go along with a 401, then it would be
nice to just have that knowledge in the class definition.
