early response with request streaming #2010
Conversation
kazuho
left a comment
There was a problem hiding this comment.
Thank you for the PR.
I like the how you refactor the HTTP/2 server stack. The state machine remains the same, however the state transitions happen regardless of if the request body is still streaming. The approach seems ideal to me.
OTOH, I am not sure if I like the introduction of on_finish callback in the httpclient API. IMO, it would be preferable to take the same approach that we have taken for the server-side code. I mean, can't we communicate the abrupt closure of the request body stream by using the proceed_req callback (possibly by extending the third argument to a tri-state value like h2o_send_state_t)?
Doing so would isolate the handling of streaming request body outside of the main state transition path (i.e. send headers -> receive headers -> receive body).
|
@kazuho Thank you for your comment. I addressed the issues |
kazuho
left a comment
There was a problem hiding this comment.
Thank you for the changes.
Below are my comments on the changes to lib/common/http1client.c. I think they are mostly fine, the comments are mostly seeking for readablity improvements.
This is unrelated to the proposed change, but I might suggest renaming on_req_chunked and on_send_request. The former is a function that is called for processing the response (hence "req" is misleading). The latter is called when the sending of a request is complete (hence "send" is misleading; maybe something like on_whole_request_sent is more appropriate).
lib/common/http1client.c
Outdated
| #include "h2o/token.h" | ||
|
|
||
| enum enum_h2o_http1client_stream_state { | ||
| STREAM_STATE_IDLE, |
There was a problem hiding this comment.
I think we might prefer omitting the prefix (i.e. h2o_http1client_ from both the typename and the names of the constants), or having prefix in both of them. They have the same visibility.
I also think that it might make sense to rename these states "~BEFORE_HEAD", "~IN_BODY", "~CLOSED". "Idle" and "open" do not naturally reflect what they are, and I was confused by the fact that you could call on_head when in "IDLE" state (i.e., can I call a callback before the stream becomes open?).
lib/common/http1client.c
Outdated
| } | ||
|
|
||
| static void on_body_error(struct st_h2o_http1client_t *client, const char *errstr) | ||
| static void close_client(struct st_h2o_http1client_t *client) |
There was a problem hiding this comment.
To me it seems that the function is actually closing the response. Am I correct?
If that is the case, I think we should rename the function to something that better reflects what the function is doing. A close_client functions sometimes just stopping the read-side of the connection to the origin is confusing.
lib/core/proxy.c
Outdated
| self->client = NULL; | ||
| detach_client(self); | ||
| h2o_req_log_error(req, "lib/core/proxy.c", "%s", "invalid response from upstream (malformed content-length)"); | ||
| h2o_send_error_502(req, "Gateway Error", "invalid response from upstream", H2O_SEND_ERROR_HTTP1_CLOSE_CONNECTION); |
There was a problem hiding this comment.
It's become now unnecessary to close the connection, the flag field can be set to 0 again. This is true for the three calls to h2o_send_error_502 in the file
… in the http1 frontend" This reverts commit 765027f.
|
@kazuho I addessed the remaining issues (http2client and mruby). could you review when you have the chance? |
|
@i110 is the failure in CI relevant to this PR? I can't tell. |
|
@deweerdt |
|
Thank you for the patience. I am looking forward to reviewing this PR next week by using it as the basis of request body handling in #1846. |
|
Regarding "request body streaming," I think we should try to become consistent in referring to the feature as "request streaming". "body streaming" is confusing because it does not clarify that it is about request body. "Request body streaming" is superfluous because we never stream headers. Hence "request streaming." |
…ng-body' into i110/early-response-with-streaming-body
d7ca0bd to
8455792
Compare
include/h2o.h
Outdated
| * indicates whether the response is being sent or not | ||
| * @param req the request | ||
| */ | ||
| static int h2o_is_sending_response(h2o_req_t *req); |
There was a problem hiding this comment.
I am going to remove this function, and directly check req->_generator != NULL in http1.c (the only code that uses this function).
The name ("is_sending_response") is inaccurate, as generator is assigned before the emission of the response starts and might remain assigned after the generator goes away (IIRC this is the case when there is a buffering ostream filter).
If a generator has been assigned is something that each protocol implementation (e.g., http1.c) can know about, and this information is only necessary to http1.c, due to HTTP/1 (ab)using an HTTP response to indicate the framing error (HTTP/2, /3 reports framing issues using frame-level errors).
There was a problem hiding this comment.
Actually mruby.c also touches req->_generator in several points to know whether it can send the response header or not, and I intended to use this function in there too after this PR gets merged. Touching req->_generator makes me a bit anxious, so we should come up with another nice name, or at least removing _ prefix from _generator if we keep touching that member directly, WDYT?
Currently there're the following problems in streaming request body if h2o gets an early response (i.e. the upstream sends the response unless waiting whole request body).
This PR aims to fix these issues.
TODOs