Avoid spurious HTTP 400 after GET to /_status #528
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This works. We can merge it, or not monitor the processes in the first place. |
After making a GET to status using a persistent HTTP/1.1 connection, the client might see a spurious HTTP 400 response (after already receiving a response to their status request). Since most clients that make requests to /_status either use HTTP 1.0 or close their connection after reading the response, they never see the 400. The 400 seems to be sent whenever the process started with spawn_monitor exits. gather_health_workers is the only function with a receive clause for the DOWN messages, but that function likely has already returned when it is received. Calling demonitor/2 with the flush option ensures those message never hit our mailbox (and are removed if they are already in our mailbox). It is unclear to me whether this represents an upstream bug in mochiweb/webmachine. ChangeLog-Entry: Fix bug where persistent clients would receive HTTP 400 after successful calls to the /_status endpoint.
stevendanna
force-pushed
the
ssd/spurious-status-400s
branch
from
5cdc9de to
2b9c719
Compare
stevendanna
added a commit
that referenced
this pull request
Sep 21, 2015
Avoid spurious HTTP 400 after GET to /_status
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After making a GET to status using a persistent HTTP/1.1 connection, the
client might see a spurious HTTP 400 response (after already receiving a
response to their status request). Since most clients that make requests
to /_status either use HTTP 1.0 or close their connection after reading
the response, they never see the 400.
The 400 seems to be sent whenever the process started with spawn_monitor
exits. gather_health_workers is the only function with a receive clause
for the DOWN messages, but that function likely has already returned
when it is recieved. Calling demonitor/2 with the flush option ensures
those message never hit our mailbox (and are removed if they are already
in our mailbox).
It is unclear to me whether this represents an upstream bug in
mochiweb/webmachine.