Repository navigation
fix(grpc): end a refused request body with grpc-status 8, not a bare reset (#426) - #430
Merged
Merged
Conversation
Contributor
CoverageTotal lines: 85.89% → 85.91% (+0.01 pp)
|
This file contains hidden or 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
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.
Fixes #426.
A refused gRPC request body (HTTP/2 and HTTP/3, in-thread and under the HTTP/3 reactor pool) ended with a bare stream reset; curl read
ENHANCE_YOUR_CALMand nogrpc-status. It now ends withgrpc-status: 8(RESOURCE_EXHAUSTED; 13 for a 500 refusal) and agrpc-message, HTTP 200, trailers-only, followed by #412's clean reset.h2_judge_refusal/h3_judge_refusal: gRPC is judged like any stream; WebSocket keeps the error reset; a gRPC response still being streamed keeps it too.grpc_call_ensure_refusal_status(H2 dispose, H3 dispose, reactor answer): status fromrefused_statuswhether the handler failed or not; a status the handler set is kept with its own message.req->grpc_mode(no worker has classified the call yet);grpc_call_init_response, status trailers promoted into the headers.readMessage()throws the refusal'sHttpExceptionat entry and when a refusal ends its wait; the H2/H3 body upgrade does nothing on a refused request. Before, a handler that caught the refusal and read again parked for good.Critic on the design (unsound, fixed) and on the diff (sound with remarks, all taken:
grpc/022lackedTRUE_ASYNC_SERVER_REACTOR_POOL=1; the wait loop threwRuntimeException0; no test of a handler's own status).Evidence (ZTS DEBUG, local):
grpc/020-025fail on main and pass 10 of 10; full phpt 635 passed, 2 skipped, 0 failed; cmocka 24 of 24. 023/024 time the upload in PHP (_grpc_h2_upload.inc, proc_open without a shell) so they run on Windows; not run on Windows locally.Not covered: gRPC-Web over HTTP/1.1 keeps the HTTP/1 413 path. On the reactor a request with a gRPC content type but no gRPC handler gets the gRPC answer (the reactor has no handler map; the cumulative-cap waiver already keys on the content type).