forward informational responses #1727

i110 · 2018-04-13T09:35:37Z

Let the proxy handler forward 1xx responses from upstream, when forward-informational is not none (default: except-h1)

TODOs:

add tests

kazuho · 2018-04-19T01:58:44Z

Thank you for working on the enhancement.

As discussed offline, we might want to simplify the approach by using h2o_req_t::res.headers for passing around the informational headers.

The downside will be that it would be impossible to pass informational response down the filters asynchronously (since we cannot allow a filter to touch them while the generator tries to fill the field with the set of header fields). But I think we can require all filters to either pass or drop informational responses synchronously, considering the fact that we want to send 103 to the client as early as possible.

…hing sending former 103

i110 · 2018-04-20T01:45:03Z

@kazuho Thank you for your comment. I did it in cbee249, fixed other problems and write some tests.

kazuho

This is beautiful. Beautiful than I had expected. Thank you for the PR.

I have left my comments, please let me know what you think.

kazuho · 2018-04-20T08:18:40Z

lib/core/request.c

+    assert(req->_generator == NULL);
+    assert(req->_ostr_top->next == NULL && req->_ostr_top->send_early_hints != NULL);
+
+    req->res.status = 103;


I would appreciate it if you could clarify whether the purpose of h2o_send_early_hints, on_send_early_hints, send_early_hints are to send an informational header that is neither 100 or 101, or if it specifically targets handling 103.

In case it is the former, the names of the function should not indicate that it is related to "early_hints", and the caller of this function should set the req->res.status to 103.

In the case of the latter, we should not set the status code to 103 here or assert that it is is 103 in the protocol implementations.

kazuho · 2018-04-20T08:20:02Z

include/h2o.h

    void (*on_context_dispose)(struct st_h2o_filter_t *self, h2o_context_t *ctx);
    void (*dispose)(struct st_h2o_filter_t *self);
    void (*on_setup_ostream)(struct st_h2o_filter_t *self, h2o_req_t *req, h2o_ostream_t **slot);
+    void (*on_send_early_hints)(struct st_h2o_filter_t *self, h2o_req_t *req);


We might want to rename it to on_early_hints. How it is being to be handled (e.g. "send") is what each protocol handler decides.

kazuho · 2018-04-20T08:20:26Z

include/h2o.h

 */
 h2o_iovec_t h2o_push_path_in_link_header(h2o_req_t *req, const char *value, size_t value_len);
+
+void h2o_send_early_hints(h2o_req_t *req);


Please add doc-comment to the public functions.

kazuho · 2018-04-20T08:23:15Z

lib/core/request.c

+{
+    /* 103 must be sent before h2o_start_response is called*/
+    assert(req->_generator == NULL);
+    assert(req->_ostr_top->next == NULL && req->_ostr_top->send_early_hints != NULL);


I think we should allow req->_ostr_top->send_early_hints being NULL for performance reasons, since for the most of the users H2O would not be emitting early hints for HTTP/1.

We can do if (req->_ostr_top->send_early_hints == NULL) return; here, and avoid the cost of running the header filters.

so what do you think about how and where should we set req->_ostr_top->send_early_hints?

the most of the users H2O would not be emitting early hints for HTTP/1.

Do you mean we should have a configuration knob which allows the users to turn off 103 forwarding only when HTTP/1 is used?

You can continue setting up the send_early_hints callback in the protocol implementations as they are. OTOH, protocol implementations that are not interested in using 103 can set send_early_hints to NULL so that the h2o_send_early_hints function can bail out earlier.

Do you mean we should have a configuration knob which allows the users to turn off 103 forwarding only when HTTP/1 is used?

I had thought that we had agreed to a knob that turns of sending 103 in any case for H1 (or both H1 and H2). Was that a discussion of a different issue?

This reverts commit 5e170f0.

i110 · 2018-04-23T07:12:33Z

@kazuho Done!

kazuho

Thank you for the changes. I have left my comments in-line. I would also appreciate if you could consider #1727 (comment).

kazuho · 2018-04-23T07:18:16Z

include/h2o.h

         */
        uint64_t first_byte_timeout;
+        /**
+         * enum indicating that the proxy forward 103 response from upstream


Please state which enum is used, or preferably, use a typed enum.

kazuho · 2018-04-23T07:19:41Z

include/h2o.h

 */
 void h2o_proxy_register_configurator(h2o_globalconf_t *conf);

+enum { H2O_PROXY_FORWARD_EARLY_HINTS_NONE, H2O_PROXY_FORWARD_EARLY_HINTS_EXCEPT_H1, H2O_PROXY_FORWARD_EARLY_HINTS_ALL };


This should not be part of the proxy, since any module (e.g. header filter) could try to emit an early hint.

you're right

i110 · 2018-04-23T07:32:00Z

@kazuho Thank you for the review. I addessed the issues.

Regarding #1727 (comment), I fixed it at
82607e3

clarify whether the purpose of h2o_send_early_hints, on_send_early_hints, send_early_hints are to send an informational header that is neither 100 or 101, or if it specifically targets handling 103.

Latter. those functions specifically target handling 103.

kazuho · 2018-04-23T07:34:52Z

include/h2o.h


 typedef H2O_VECTOR(h2o_status_handler_t) h2o_status_callbacks_t;
+
+typedef enum h2o_forward_early_hint {


should be "early hints" throughout the PR, especially when dealing with a set of header fields. This is because each header field of an 103 response is a "hint".

kazuho · 2018-04-23T07:36:46Z

lib/core/proxy.c

    }

+    if (status == 103) {
+        self->src_req->res.status = 103;


h2o_send_early_hints is a function specific to handling 103. That would mean that it sends a set of header fields and not the status code itself as an argument.

Therefore, we should not set h2o_req_t::res.status to 103 or expect the value to be that.

kazuho · 2018-04-23T07:37:43Z

lib/handler/configurator/proxy.c

    h2o_configurator_define_command(&c->super, "proxy.max-buffer-size",
                                    H2O_CONFIGURATOR_FLAG_ALL_LEVELS | H2O_CONFIGURATOR_FLAG_EXPECT_SCALAR,
                                    on_config_max_buffer_size);
+    h2o_configurator_define_command(&c->super, "proxy.forward-early-hints",


Please adjust how the configuration directives and possible other parts of the code that implies the feature to be specific to the reverse proxy.

i110 · 2018-04-24T11:14:22Z

@kazuho Thank you. I addressed the issues.

kazuho

Thank you for the changes. With the changes, I think that the code better reflects what an ideal proxy should do (in conformance to RFC).

I have left my ideas regarding the design of the protocol implementation. Please let me know what you think.

kazuho · 2018-04-25T00:15:04Z

lib/core/request.c

+    /* 1xx must be sent before h2o_start_response is called*/
+    assert(req->_generator == NULL);
+    assert(req->_ostr_top->next == NULL);
+    assert(100 <= req->res.status && req->res.status <= 199);


Maybe add assert(req->res.status != 101) as well?

kazuho · 2018-04-25T01:24:37Z

lib/http1.c

+        struct {
+            h2o_iovec_t *inbufs;
+            size_t inbufcnt;
+            h2o_send_state_t send_state;


I can see that we need to buffer the content passed from the generator, now that informational responses could be in flight.

Then, can't we simplify the logic by using the same buffer for storing any pending data, including when we receive an additional 103 while a previous 103 is in flight?

@kazuho Thank you for the comment. By this comment I found that req->res.headers can be modified while sending 1xx responses, and it'll cause some problems. I fixed that issue at bd7e9a1.

OTOH,

Then, can't we simplify the logic by using the same buffer for storing any pending data, including when we receive an additional 103 while a previous 103 is in flight?

I tried to simplify by buffering final responses too, but it may cause some performance disadvantages, so I left pending_final as it is.

…110/forward-early-hints

kazuho

Thank you for the changes.

I have left my tentative comments. Please let me know what you think.

kazuho · 2018-05-11T09:09:00Z

include/h2o.h

+    H2O_FORWARD_INFORMATIONAL_NONE,
+    H2O_FORWARD_INFORMATIONAL_EXCEPT_H1,
+    H2O_FORWARD_INFORMATIONAL_ALL
+} h2o_forward_informational_t;


Current name looks like a callback rather than a enum, because "forward" is a verb.

Please consider changing the phrase "h2o_forward_informational" to "h2o_forward_informational_mode" or something (i.e. change the name to h2o_forward_informational_mode_t, ..._NONE to ..._MODE_NONE).

kazuho · 2018-05-11T09:15:23Z

lib/core/proxy.c

    /* copy the response (note: all the headers must be copied; http1client discards the input once we return from this callback) */
    req->res.status = status;
    req->res.reason = h2o_strdup(&req->pool, msg.base, msg.len).base;
+    req->res.headers = (h2o_headers_t){NULL, 0, 0};


Do we need to reset fields other than size?

Consider the case where the server sends an informational response containing 50 header fields, and then sending a final response containing the same number of header fields. I would prefer not to expand the buffer twice to store the headers. This is a weak preference, but I do not see why it can simply be done by not resetting the other fields.

I would prefer not to expand the buffer twice to store the headers.

No, when sending 1xx we're not allocating or expanding any vectors or buffers

h2o/lib/core/proxy.c

Line 578 in b43efc4

self->src_req->res.headers = (h2o_headers_t){headers, num_headers, num_headers};

If there're no performance reasons, I'd prefer to clear whole struct explicitly rather than leaving broken pointer (req->res.headers.entries).

Or, we might should clear req->res.headers at the end of h2o_send_informational..

IMO it would depend on how an output filter (e.g. the headers handler) initiates Early Hints, when a generator that does not immediately return a final response is used.

Clearing req->res.headers would be fine if h2o_send_informational is going to be used for such purposes as well. Otherwise, we should clear the field in each protocol implementation, at the moment they serialize the headers to send them.

Clearing req->res.headers would be fine if h2o_send_informational is going to be used for such purposes as well.

Yes, I think h2o_send_informational will be used for such use cases. d6e1e3b made it clear req->res

kazuho · 2018-05-11T09:21:43Z

include/h2o.h

+    /**
+     * enum indicating that h2o forward 1xx response from upstream
+     */
+    h2o_forward_informational_t forward_informational;


The doc-comment says the enum indicates if 1xx from upstream is forwarded.

Is that true?

My understanding is that this function controls if protocol handlers sends 1xx responses. In other words, this property controls what h2o sends rather than what it forwards (consider the hypothetical case of a file handler emitting 1xx; it's not "upstream", since in such case h2o is the origin).

Considering that, I'd prefer renaming this from "forward_informational_mode" to "send_informational_mode" (see my other comment about appending "_mode").

kazuho · 2018-05-11T09:23:37Z

lib/core/configurator.c


+static int on_config_forward_informational(h2o_configurator_command_t *cmd, h2o_configurator_context_t *ctx, yoml_t *node)
+{
+    int value;


Can't the type of the value be the enum that is being typedef'ed? I'd assume that it can be, and that you could then omit the cast when assigning the value to globalconf.

kazuho · 2018-05-11T09:33:56Z

lib/http1.c

-        *dst++ = '\r';
-        *dst++ = '\n';
-    }
+    dst += flatten_normal_headers(dst, req->res.headers.entries, req->res.headers.size, is_msie(req));


This change causes performance degradation.

In current code, is_msie (which is a slow function) is called only when a vary header is being emitted. The PR is changing the function to be always called.

i110 · 2018-05-11T10:32:55Z

@kazuho thank you for the comments. I addressed the issues.

kazuho · 2018-05-11T10:50:49Z

include/h2o.h

+    H2O_HEADERS_CMD_WHEN_FINAL,
+    H2O_HEADERS_CMD_WHEN_EARLY,
+    H2O_HEADERS_CMD_WHEN_ALL,
+} h2o_headers_command_when_t;


What's the default value? I would suggest moving the default value to the top so that it would be assigned zero.

Yes, default value is H2O_HEADERS_CMD_WHEN_FINAL

kazuho · 2018-05-11T10:56:14Z

t/50reverse-proxy-informational.t

+            (my $eh, $resp) = split(/\r\n\r\n/, $resp, 2);
+            like $eh, qr{^link: </index.js>; rel=preload}mi if $link;
+
+            if ($status == 103) {


Don't we need to test that the server is actually sending 103 here?

I believe that the test would succeed even if the server did not send 103, all the 103-related tests are under if ($status == 103).

PS. In particular, I am thinking how we test the behavior of the HTTP/2 protocol implementation.

kazuho · 2018-05-21T03:12:43Z

Thank you for working on the feature!

i110 added 2 commits April 13, 2018 18:20

move h2o_header_t definition to header.h

5e170f0

forward 103 early hints response

1549a95

i110 added 7 commits April 20, 2018 09:07

add status condition

176e9b0

use req->res.headers to send early hints

cbee249

fixup

c9e7874

fix pointer calculation bug

13f9977

properly handle multiple 103 and final response received before finis…

e5d7aa5

…hing sending former 103

add tests for forwarding early hints

74433ce

Merge branch 'master' into i110/forward-early-hints

dda3fc5

kazuho reviewed Apr 20, 2018

View reviewed changes

i110 added 6 commits April 22, 2018 22:06

on_send_early_hints -> on_early_hints

8c8a408

Revert "move h2o_header_t definition to header.h"

1081a9f

This reverts commit 5e170f0.

add doc-comment

a897e4b

set response status at proxy.c

82607e3

make forward-early-hints knob tri-state and set default to except-h1

797f7e2

clang-format

a1bbcbf

kazuho reviewed Apr 23, 2018

View reviewed changes

define h2o_forward_early_hint_t

f65129e

kazuho reviewed Apr 23, 2018

View reviewed changes

i110 added 5 commits April 24, 2018 15:50

rename

d4dc486

forward not only 103, but all 1xx responses except 101

d1171ea

fixup

e41e993

proxy.forward-early-hints => forward-early-hints

d79a7ed

fixup

4f4f3f4

i110 added 3 commits April 24, 2018 18:38

fix tests

6a0c221

apply headers filter only when 103

09f4a96

add when configuration to header commands

104b3bc

i110 changed the title ~~forward early hints~~ forward informational responses Apr 24, 2018

don't send 1xx to HTTP/1.0 clients

4124fcd

i110 force-pushed the i110/forward-early-hints branch from ba7d52f to 4124fcd Compare April 24, 2018 11:13

make header directive be able to accept sequence

de76def

kazuho reviewed Apr 25, 2018

View reviewed changes

i110 added 5 commits April 25, 2018 16:04

exclude 101

f59a0cd

Merge branch 'master' into i110/forward-early-hints

2be27ec

reserve buffers for informational responses

bd7e9a1

reformat

bd1f09c

Merge remote-tracking branch 'origin/i110/forward-early-hints' into i…

b43efc4

…110/forward-early-hints

kazuho reviewed May 11, 2018

View reviewed changes

i110 added 3 commits May 11, 2018 18:59

tweak names

9347950

assign directly

646b904

don't call is_msie until needed

d1a99c3

kazuho reviewed May 11, 2018

View reviewed changes

i110 added 3 commits May 11, 2018 20:30

add test cases

6965e9c

change the order of enum

f7ad19b

clear req->res at the end of h2o_send_informational

d6e1e3b

kazuho merged commit 6c7c850 into master May 21, 2018

i110 mentioned this pull request May 30, 2018

Why doesn't h20 forwards Early hint headers to client (bowser) #1771

Closed

i110 mentioned this pull request Aug 3, 2018

fix broken memory problem on keepalived connection #1823

Merged


		typedef H2O_VECTOR(h2o_status_handler_t) h2o_status_callbacks_t;

		typedef enum h2o_forward_early_hint {

forward informational responses #1727

forward informational responses #1727

Uh oh!

Conversation

i110 commented Apr 13, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kazuho commented Apr 19, 2018

Uh oh!

i110 commented Apr 20, 2018

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!

i110 Apr 22, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

i110 commented Apr 23, 2018

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!

i110 commented Apr 23, 2018

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!

i110 commented Apr 24, 2018

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!

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!

i110 May 11, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

i110 May 11, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

i110 May 12, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

i110 commented Apr 13, 2018 •

edited

Loading

i110 Apr 22, 2018 •

edited

Loading

i110 May 11, 2018 •

edited

Loading

i110 May 11, 2018 •

edited

Loading

i110 May 12, 2018 •

edited

Loading