Skip to content

The Server should always have a request listener #122

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

Merged
merged 1 commit into from
Feb 20, 2017

Conversation

clue
Copy link
Member

@clue clue commented Feb 17, 2017

Having an HTTP server with no request listener does not really make any sense at all.

Currently, the end() call actually results in an invalid HTTP response stream, because it sends a closing chunk (chunked transfer encoding) without actually sending any HTTP response headers.

This simple PR changes it so that this case will simply not be handled at all, so that the client never receives any response data at all. This is actually in line with how our Socket component works if there's no connection listener.

Note that the invalid response stream will that is sent by end() will be addressed in a separate ticket, I'll link to this here once it's ready.

@clue clue added this to the v0.6.0 milestone Feb 17, 2017
@clue
Copy link
Member Author

clue commented Feb 19, 2017

Rebased now that #125 is in :shipit:

@WyriHaximus WyriHaximus merged commit b90e080 into reactphp:master Feb 20, 2017
@clue clue deleted the no-listener branch February 21, 2017 06:55
@clue
Copy link
Member Author

clue commented Feb 21, 2017

Note that the invalid response stream will that is sent by end() will be addressed in a separate ticket, I'll link to this here once it's ready.

See #131

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

Successfully merging this pull request may close these issues.

3 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy