close
The Wayback Machine - https://web.archive.org/web/20210723114116/https://github.com/http-party/http-server/issues/634
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server Crashing with "Cannot set headers after they are sent to the client" #634

Open
Inrixia opened this issue Jun 7, 2020 · 1 comment
Open

Comments

@Inrixia
Copy link

@Inrixia Inrixia commented Jun 7, 2020

Steps to reproduce the issue, if applicable. Include the actual command and output and/or stack trace.

Not sure sorry as there is a lot of traffic on the server, just appears to all be normal GET requests.

What did you expect to happen?
The server to not crash. Ideally the error would be returned as a 503.

_http_outgoing.js:485
    throw new ERR_HTTP_HEADERS_SENT('set');
    ^

Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
    at ServerResponse.setHeader (_http_outgoing.js:485:11)
    at module.exports.ResponseStream.<computed> [as setHeader] (C:\Users\Administrator\AppData\Roaming\npm\node_modules\http-server\node_modules\union\lib\response-stream.js:100:34)
    at Object.exports.<computed> (C:\Users\Administrator\AppData\Roaming\npm\node_modules\http-server\node_modules\ecstatic\lib\ecstatic\status-handlers.js:57:7)
    at ReadStream.<anonymous> (C:\Users\Administrator\AppData\Roaming\npm\node_modules\http-server\node_modules\ecstatic\lib\ecstatic.js:298:24)
    at ReadStream.emit (events.js:223:5)
    at internal/fs/streams.js:167:12
    at FSReqCallback.wrapper [as oncomplete] (fs.js:470:5) {
  code: 'ERR_HTTP_HEADERS_SENT'
}

Tell us about your environment
Windows Server 2016
Node.js v12.14.1
Latest Version (Embedded/Global CLI Version from NPM)

Other information (related issues, suggestions for a fix, etc):
As far as I am aware the only thing that really needs to be done is catching the error and returning 503.

@Inrixia
Copy link
Author

@Inrixia Inrixia commented Jun 10, 2020

Currently I am just using a catch-all error handler and running off the source code rather than the global package. So just having a handler for that error would be a quick fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants