[http1] streaming request bodies #2007

deweerdt · 2019-03-15T03:41:01Z

This commit introduces the infrastructure needed to stream request bodies
for http1, we have the two readers, chunked and content-length use the
h2o_req_t::write_req.cb to emit body chunks.

This commit introduces the infrastructure needed to stream request bodies for http1, we have the two readers, chunked and content-length use the h2o_req_t::write_req.cb to emit body chunks.

…reaming-request-bodies

kazuho

Thank you for the PR. I haven't gone through the code, but I noticed following points that you might want to look into.

Regarding the test failure, I am not sure what's happening. IIUC the test that fails now does not involve a request body, and therefore should continue to work fine, assuming that the behavior of the http1 handler has not changed for requests without bodies. Am I missing something here?

lib/http1.c

…Ichito for spotting this

deweerdt · 2019-03-18T17:09:30Z

Thank you @i110 and @kazuho I didn't realize the error failure was coming from the non-streaming case. Addressed. I've also addressed the issue pointed out by @kazuho above. I believe this can be cleaned up by merging some of the streaming infrastructure used by http1 and http2. I'll take a stab at that.

…f the request

code under lib/core/request.c

kazuho

Thank you for the PR.

The high level design looks fine, and I like how you've refactored the code so that the some of the logic is shared between the http1 stack and http2 stack. I think we'd might want to make further tweaks (including @i110's point that the selection between streaming and non-streaming mode does not need to be delayed), but I am fine with doing it in a separate PR if that's preferable for you.

Regarding the changes to HTTP/1 stack, I think I have found some corner cases (see below). They make me wonder what we should do with the lack of tests covering the error cases and pipelining. Would you be interested in writing them, or do you want somebody more familiar to perl to work on the issue (thinking of @i110 or myself)?

kazuho · 2019-03-22T09:24:04Z

lib/http1.c

-    /* all input has arrived */
-    conn->req.entity = h2o_iovec_init(conn->sock->input->bytes + conn->_reqsize - reader->content_length, reader->content_length);
-    on_entity_read_complete(conn);
+    handle_one_body_fragment(conn, conn->sock->input->size, complete);


Doesn't this process excessive amount of input as request body if the last input consists of the end of the request body and the first few bytes of the next request (i.e. pipelining)?

Please correct me if I'm incorrect, and if we have a test covering such case.

That's right, i've added a test in fb8e95b that shows the previous code was broken. This is fixed now.

kazuho · 2019-03-22T09:26:24Z

lib/http1.c

        return;
    }

+    if (conn->req.proceed_req) {


I'd appreciate it if you could add != NULL. We apply operators so that the result would be a boolean, unless the input (being an integral value) is considered a boolean (due to lack of a built-in boolean type in C).

Adressed in c3bcd0d thank you.

kazuho · 2019-03-22T09:29:59Z

lib/http1.c

+    if (conn->req.proceed_req) {
+        conn->_req_entity_reader = NULL;
+        set_timeout(conn, 0, NULL);
+        h2o_socket_read_stop(conn->sock);


I'm not sure if this is the right moment. Don't we need to disarm the timeout and stop reading additional bytes every time when we pass something to the handler? Otherwise, the amount of data we buffer cannot be capped.

Addressed in e4d894b

e4d894b looks good to me, but would you mind elaborating why we need to stop reading (or consider the case of conn->req.proceed_req being non-NULL) in this function, after consulting the value of conn->req.http1_is_persistent?

It is my understanding that cleanup_connection is called only when the HTTP/1 stack successfully processes a request and sending a response. Assuming that is still the case, I think proceed_req and _req_entity_reader must have been set to NULL, and reading from the socket should have been stopped. Maybe what we need are assertions.

I've added assertions, thanks for the suggestion.

I've added assertions, thanks for the suggestion.

And the assertions found that 603c731 is necessary because h2o_send_error can complete the request without closing the connection.

…equest-bodies

…-encoding:chunked While the behavior is technically correct, dropping content-length: loses information that might be valuable to other peers down the path. We fix this by making sure that `req.content_length` is correctly assigned for http/1 when available. It was already correctly initialized in the http/2 case.

connection to the origin is established, effecitively disabling streaming

deweerdt · 2019-04-09T17:34:04Z

@kazuho i believe fa4fa74 addresses all your comments so far. I also have a test branch that integrates with @i110 's #2010 which looks good.

kazuho

Thank you for the changes. Looks mostly fine to me, some nitpicks below. PTAL.

kazuho · 2019-04-11T06:17:25Z

include/h2o.h


 typedef void (*h2o_proceed_req_cb)(h2o_req_t *req, size_t written, int is_end_stream);
 typedef int (*h2o_write_req_cb)(void *ctx, h2o_iovec_t chunk, int is_end_stream);
+typedef void (*h2o_on_body_streaming_selected_cb)(h2o_req_t *, int streaming);


I might suggest changing the typename and the prototype argument to something like:

typedef void (*h2o_on_request_streaming_selected_cb)(h2o_req_t *req, int is_streaming);

By changing "body_streaming" to "request_streaming", we avoid the confusion that this is related to response streaming. We can omit "body", because body is the only thing we stream.

Adding "is_" prefix better aligns the callback type with other functions that also accept boolean arguments (see right above).

Note also the the support of the feature is indicated by a property named supports_request_streaming in h2o_handler_t.

kazuho · 2019-04-11T06:18:28Z

include/h2o.h

    struct {
        h2o_write_req_cb cb;
        void *ctx;
+        h2o_on_body_streaming_selected_cb on_body_streaming_selected;


The name of the attribute can be write_req.on_streaming_selected instead of write_req.on_body_streaming_selected if we follow the rules stated above.

kazuho · 2019-04-11T06:19:31Z

include/h2o.h

+    struct {
+        size_t bytes_received;
+        h2o_buffer_t *body;
+    } _body;


s/_body/_req_body/

kazuho · 2019-04-11T06:41:41Z

lib/http1.c

+        entity_read_send_error_502(conn, "Bad Gateway", "Bad Gateway");
+        return;
+    }
+    h2o_buffer_consume(&conn->sock->input, consume);


I think that we can omit the third argument of the function and do h2o_buffer_consume(&conn->sock->input, fragment_size) here.

The only case where fragment_size and consume are different in the current code is when chunked encoding is used. I'd argue that for such a case, the caller can invoke h2o_buffer_consume at first to consume the chunk header, then invoke handle_one_body_fragment to just process the payload of the chunk.

h2o_buffer_consume is a fast function, and processing of a chunked request is not a cold path (because only clients that know that the server supports HTTP/1.1 would use it).

kazuho · 2019-04-11T06:48:17Z

lib/http1.c

    set_timeout(conn, 0, NULL);
    h2o_socket_read_stop(conn->sock);
-    process_request(conn);
+}


I think we should inline-expand the body of this function in handle_one_body_fragment (that's the only call-site), preferably before we call write_req.

kazuho · 2019-04-11T06:53:26Z

lib/http1.c

+    return 0;
+}
+
+static void on_body_streaming_selected(h2o_req_t *req, int streaming)


s/streaming/is_streaming/

kazuho · 2019-04-11T06:54:17Z

lib/http2/connection.c

 }

-static int write_req_first(void *_req, h2o_iovec_t payload, int is_end_stream)
+static void on_body_streaming_selected(h2o_req_t *req, int streaming)


s/on_body_streaming_selected/on_request_streaming_selected/
s/int streaming/int is_streaming/

kazuho · 2019-04-11T07:00:07Z

lib/http1.c

    uint64_t _req_index;
    size_t _prevreqlen;
-    size_t _reqsize;
+    size_t _headers_size;


I would appreciate it if you could either change the name of the variable to something more appropriate, or add a comment explaining how the value is used.

This is because the value does not always represent the size of the header fields with the proposed change (when the request has a body, it becomes zero). It is my understanding that the amount of data left un-consumed in the socket read buffer.

I've gone with _unconsumed_request_size

kazuho · 2019-04-11T07:06:38Z

lib/http1.c

+    if (conn->req.proceed_req) {
+        conn->_req_entity_reader = NULL;
+        set_timeout(conn, 0, NULL);
+        h2o_socket_read_stop(conn->sock);


e4d894b looks good to me, but would you mind elaborating why we need to stop reading (or consider the case of conn->req.proceed_req being non-NULL) in this function, after consulting the value of conn->req.http1_is_persistent?

It is my understanding that cleanup_connection is called only when the HTTP/1 stack successfully processes a request and sending a response. Assuming that is still the case, I think proceed_req and _req_entity_reader must have been set to NULL, and reading from the socket should have been stopped. Maybe what we need are assertions.

- s/_body/_req_body/ - s/on_body_streaming_selected/on_streaming_selected/ - s/h2o_on_body_streaming_selected_cb/h2o_on_request_streaming_selected_cb/

…reaming_selected/

going through `cleanup_connection` and `http1_is_persistent` is false

…http1 frontend

deweerdt · 2019-04-13T02:57:26Z

@kazuho i believe that 765027f addresses all you comments so far. A change that wasn't covered in the previous exchange is the connection close on the proxy 502s. Any thoughts on that?

kazuho · 2019-04-15T06:52:50Z

A change that wasn't covered in the previous exchange is the connection close on the proxy 502s. Any thoughts on that?

IIUC, the proposed change is to suggest closing the connection from proxy.c whenever it is impossible to connect to the origin. I am not sure if that is the correct thing to do.

At the moment, we close a H1 connection only when the framing becomes corrupt (i.e. when there would be a risk of splitting attack unless we close the connection). In case of an origin sending 502, the framing is not necessarily corrupt. It is beneficial to keep the connection open especially when only some of the requests are routed to an origin, while other requests being served by H2O itself.

I think we might want to consider the case you are trying to fix as part of #2010. The proxy handler returning 502 due to not being able to connect to an origin while the request from the client being inflight is a particular form of returning an early response. I am not sure of how we should handle the error, but my instinct is that it's something not unique to the proxy handler, but rather something general to all the handlers.

kazuho · 2019-04-15T07:29:08Z

@deweerdt Regarding my previous comment, I asked @i110 on how he deals with the issue in H2, and his answer was than in #2010 the stream is closed by the proceed_req callback:

h2o/lib/http2/connection.c

Line 657 in 24d2036

stream_send_error(conn, stream->stream_id, H2O_HTTP2_ERROR_NONE);

I think this approach might be something we should adopt in H1 as well (or change to a different approach in both H1 and H2 code). WDYT?

deweerdt · 2019-04-15T20:04:18Z

I think this approach might be something we should adopt in H1 as well (or change to a different approach in both H1 and H2 code). WDYT?

That would work for me. Would you prefer a combined PR with #2007 and #2010 ?

kazuho · 2019-04-15T23:49:21Z

That would work for me. Would you prefer a combined PR with #2007 and #2010 ?

That's a good question. Yeah, let's tackle the issues independently. I think we can land the code here (that uses H2O_SEND_ERROR_HTTP1_CLOSE_CONNECTION) as-is, and fix it later in #2010 or in a follow-up PR of #2010.

Using H2O_SEND_ERROR_HTTP1_CLOSE_CONNECTION has efficiency issues, but works perfect as a short-term solution.

deweerdt · 2019-04-16T03:51:30Z

That's a good question. Yeah, let's tackle the issues independently. I think we can land the code here (that uses H2O_SEND_ERROR_HTTP1_CLOSE_CONNECTION) as-is, and fix it later in #2010 or in a follow-up PR of #2010.

That works. There's code more or less ready anyway, since i've tested an earlier version of this PR+2010 to help review #2010.

kazuho · 2019-04-16T05:51:23Z

Thank you for working on this complex PR. Merged to master.

deweerdt added 2 commits March 14, 2019 11:01

[http1] streaming request bodies

3ca1e56

This commit introduces the infrastructure needed to stream request bodies for http1, we have the two readers, chunked and content-length use the h2o_req_t::write_req.cb to emit body chunks.

Merge remote-tracking branch 'upstream/master' into deweerdt/http1-st…

2c0ebf8

…reaming-request-bodies

deweerdt changed the title ~~Http1 streaming request bodies~~ [http1] streaming request bodies Mar 15, 2019

kazuho reviewed Mar 16, 2019

View reviewed changes

lib/http1.c Outdated Show resolved Hide resolved

lib/http1.c Outdated Show resolved Hide resolved

lib/http1.c Outdated Show resolved Hide resolved

deweerdt added 2 commits March 18, 2019 09:19

Only call h2o_process_request once in the non-streaming case, thanks …

6543d95

…Ichito for spotting this

Fix error handling by adding a 502 error case for the entity reader

1804a40

deweerdt added 7 commits March 19, 2019 09:55

Have http/1 and http/2 use the same struct in req to store the body o…

1ff0a2d

…f the request

Rename _req_body to _body

1119ce7

Factorize error handling in writing body fragments

4ba7add

Fix issue introduced in 4ba7add

8ae62ad

Simplify the logic for handle_content_length_entity_read

3bcc41c

Factorize the write_req_first callback from http1 and http2 to common

154ba55

code under lib/core/request.c

Fix issue introduced in 3bcc41c

909993f

kazuho reviewed Mar 22, 2019

View reviewed changes

deweerdt added 7 commits March 22, 2019 12:53

Merge remote-tracking branch 'upstream/master' into http1-streaming-r…

66f7aa7

…equest-bodies

Fix pipelining case

fb8e95b

Fix pointer used as a boolean

c3bcd0d

Set/unset the timeout as body fragments are handled

e4d894b

Use the correct function to restart reading the body

9528022

Make a larger file, to avoid having the whole file posted before the

d64bae2

connection to the origin is established, effecitively disabling streaming

deweerdt force-pushed the http1-streaming-request-bodies branch from becf577 to fbec251 Compare April 9, 2019 16:33

deweerdt added 2 commits April 9, 2019 09:34

dont send if headers were sent, remove bogus buffer consume

3a57516

_reqsize -> _headers_size

fa4fa74

deweerdt force-pushed the http1-streaming-request-bodies branch from fbec251 to fa4fa74 Compare April 9, 2019 16:38

kazuho reviewed Apr 11, 2019

View reviewed changes

deweerdt added 2 commits April 12, 2019 15:47

streaming body renames

13db132

- s/_body/_req_body/ - s/on_body_streaming_selected/on_streaming_selected/ - s/h2o_on_body_streaming_selected_cb/h2o_on_request_streaming_selected_cb/

inline on_entity_read_complete

f305800

deweerdt added 6 commits April 12, 2019 16:01

rename: s/_headers_size/_unconsumed_request_size/

76e6f67

Omit the third argument to handle_one_body_fragment

7ffebda

rename: s/streaming/is_streaming/, s/on_body_streaming_selected/on_st…

1e11be7

…reaming_selected/

Assert that the request streaming has completed correctly, if we're

8d05ca0

going through `cleanup_connection` and `http1_is_persistent` is false

s/on_streaming_selected/on_request_streaming_selected/

420589c

Make sure that proxying errors are sent with connection:close in the …

765027f

…http1 frontend

deweerdt force-pushed the http1-streaming-request-bodies branch from 603c731 to 765027f Compare April 13, 2019 01:58

kazuho mentioned this pull request Apr 15, 2019

QUIC (HTTP3) support #1846

Merged

10 tasks

kazuho merged commit c14554e into h2o:master Apr 16, 2019

kishorenc mentioned this pull request May 19, 2020

more support for request streaming #1601

Open

3 tasks

[http1] streaming request bodies #2007

[http1] streaming request bodies #2007

Uh oh!

Conversation

deweerdt commented Mar 15, 2019

Uh oh!

kazuho left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

deweerdt commented Mar 18, 2019

Uh oh!

kazuho left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deweerdt commented Apr 9, 2019

Uh oh!

kazuho left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deweerdt commented Apr 13, 2019

Uh oh!

kazuho commented Apr 15, 2019

Uh oh!

kazuho commented Apr 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

deweerdt commented Apr 15, 2019

Uh oh!

kazuho commented Apr 15, 2019

Uh oh!

deweerdt commented Apr 16, 2019

Uh oh!

kazuho commented Apr 16, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

kazuho commented Apr 15, 2019 •

edited

Loading