No addr needed for accept

[jbr]

because the host header is mandatory for http/1.1, the addr argument to accept is unnecessary and unused. this builds upon #106

[yoshuawuyts]

because the host header is mandatory for http/1.1

@jbr I was looking through the http/1.1 RFC and couldn't find the section explaining this. Do you have a reference? It's probably worth adding a comment with a link to that section inside the source as well for future reference.

edit: Also worth pointing out that this would prevent us from adding HTTP/1.0 support since the HOST Header would not be required there.

edit: confusingly RFC 2616 does mention HOST header fields being required by clients to be sent (ref) but that is not mentioned in RFC 7231 which obsoletes RFC 2616. It's also not mentioned in the "changes from 2616" section so I'm assuming both RFCs need to be read in order to understand the full protocol (or maybe it's mentioned in RFC 7231 but still missing it).

edit: there we go, RFC 7231 refers to RFC 7230 which specifically covers HTTP headers and includes this section. We should probably link to this from the source (:

[jbr]

https://tools.ietf.org/html/rfc7230#section-5.4

[jbr]

Added a comment url to the rfc in 0999baf as well.

As far as this being an incompatible change for potential http/1.0 support later: I did consider that and should have typed up my thinking on it. I anticipate that adding 1.0 support will be a substantial refactor with any number of interface changes and that in somewhat extreme-programming/yagni fashion, we not try to anticipate the shape of those changes until someone is actually looking at making that change. Even for http/1.0, it doesn't seem like the locally-bound ip and port (or filesystem socket) is the appropriate default for the url base, and it's possible that the domain would need to be provided as an explicit and distinct configuration option by the user, like "listen on 0.0.0.0:3000, but use a default url base of example.com," especially since some 12-factor type deployments will likely want to configure those two settings independently through an env var.

[yoshuawuyts]

The reasoning in this PR is sound; I like these changes. Also it'll make building #104 substantially easier!