ORIGIN frame #1199

deweerdt · 2017-02-12T03:45:46Z

This introduces a new option: http2-origin-frame. It can be either a
scalar or a sequence. When this option is sent, H2O sends an ORIGIN
frame as described here:
https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-origin-frame.md

The PR is mostly intended to serve as basis for the discussion, rather than intended for merging. It feels like the contents of ORIGIN frame we send should actually depend on the SNI as follows:

Config defines an SNI to host names mapping
SNI callback adds the SNI to h2o_conn_t
expect_preface looks up the SNI in h2o_conn_t and using the config mapping, builds the ORIGIN frame

Thoughts?

This introduces a new option: `http2-origin-frame`. It can be either a scalar or a sequence. When this option is sent, H2O sends an ORIGIN frame as described here: https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-origin-frame.md

kazuho · 2017-02-13T04:44:17Z

Thank you for opening the PR and starting the discussion.

It seems like that we need to consider how we should design the configuration directives for the frame. I do not have a concrete idea on how the design should be, but trying to find a good way to handle a configuration like below might be a good starting point.

hosts:
    a.example.com:
        ssl:
            port: 443
            certificate-file: wildcard.example.com.crt
    b.example.com:
        ssl:
            port: 443
            certificate-file: wildcard.example.com.crt
    c.example.org:
        ssl:
            port: 443
            certificate-file: c.example.org.crt
    "d.example.net:8443":
        ssl:
            port: 8443
            certificate-file: d.example.net.crt
            ...

For this example, an ORIGIN frame should not be sent when accepting a connection on port 443 with value of the SNI extension set to c.example.org. For connections with other SNIs being accepted on port 443, an ORIGIN frame may be sent (depending on the configuration variables) with its value set to a.example.com and b.example.com. For connections arriving on port 8443, we do not have a need to send an ORIGIN frame.

I am not sure what the correct answer would be, but looking at this example it seems that having a configuration directive for controlling ORIGIN frames next to certificate-file (or maybe next to ssl) seems like a good solution.

Move the config logic under the ssl listener config

deweerdt · 2017-02-14T00:38:29Z

@kazuho thank you for your suggestion. 1194084 moves the config item under ssl, as such:

hosts:
    a.example.com:
        ssl:
            port: 443
            certificate-file: wildcard.example.com.crt
            http2-origin-frame: "https://a.example.com"
    b.example.com:
        ssl:
            port: 443
            certificate-file: wildcard.example.com.crt
            http2-origin-frame: [ "https://img.b.example.com", "https://b.example.com" ]
    c.example.org:
        ssl:
            port: 443
            certificate-file: c.example.org.crt
    "d.example.net:8443":
        ssl:
            port: 8443
            certificate-file: d.example.net.crt
            ...

I think a remaining question is whether we want to handle the "*" case in the config as well, something like:

hosts:
    *:
        ssl:
            port: 443
            certificate-file: wildcard.example.com.crt
            http2-origin-frame:
               a.example.com: "https://a.example.com"

But that might be overkill, what do you think?

kazuho

Thank you for the updates. I think we are on the right track. I've left some (relatively minor) comments. Please let me know what you think.

kazuho · 2017-02-14T01:02:00Z

lib/http2/connection.c

 }

-void h2o_http2_accept(h2o_accept_ctx_t *ctx, h2o_socket_t *sock, struct timeval connected_at)
+void h2o_http2_accept(h2o_accept_ctx_t *ctx, h2o_socket_t *sock, h2o_iovec_t *http2_origin_frame, struct timeval connected_at)


Do we need to pass http2_origin_frame as a separate argument? To me, using the value in ctx seems fine.

kazuho · 2017-02-14T01:05:08Z

include/h2o.h

+    struct {
+        SSL_CTX *ssl_ctx;
+        h2o_iovec_t *http2_origin_frame;
+    } ssl;


Let's not move ssl_ctx into a new field, but have both ssl_ctx and http2_origin_frame direct members of h2o_accept_ctx_t.

The reasons are: 1. the change would be smaller 2. in terms of protocol, origin frames can be sent even when SSL is not used.

Done. Regarding 2. my understanding of the RFC is that SSL has to be used?

kazuho · 2017-02-14T01:12:45Z

src/main.c

+                         h2o_strtolower(elems[i*2 + 1].base, elems[i*2 + 1].len);
+                     }
+                     http2_origin_frame = h2o_mem_alloc(sizeof(*http2_origin_frame));
+                     *http2_origin_frame = h2o_concat_list(NULL, elems, value->data.sequence.size * 2);


How about creating a function that takes a list of strings to build the frame, instead of having duplicate code for YOML_TYPE_SCALAR and YOML_TYPE_SEQUENCE?

deweerdt · 2017-02-14T20:19:59Z

@kazuho I believe d6e1850 addresses all your comments so far.

kazuho · 2017-02-15T01:07:05Z

src/main.c

    ssl_config->hostnames.entries[ssl_config->hostnames.size++] = h2o_iovec_init(host.base, host_end - host.base);
 }

+static h2o_iovec_t *build_http2_origin_frame(const h2o_iovec_t *origins, size_t nr_origins)


Would it make sense to change the signature of this function to: (h2o_configurator_command_t *cmd, yoml_t *origins, size_t nr_origins)?

If the argument to the directive was a scalar, the caller can just call build_http2_origin_frame(cmd, value, 1). If the argument to the directive was a sequence, the caller should call build_http2_origin_frame(cmd, value.data.sequence.elements, value.data.sequence.size).

deweerdt · 2017-02-16T16:27:50Z

42c8fdd has a better interface for build_http2_origin_frame. Thank you for the suggestion, @kazuho .

kazuho · 2017-02-22T21:56:41Z

@deweerdt Thank you very much. The code looks perfect!

Let's keep this parked and merge it once we see the draft go forward and/or when we see clients start recognizing the frame.

> The ORIGIN frame type is 0xc (decimal 12)

deweerdt · 2017-10-20T17:42:29Z

3b749c0 updates the branch to current master and updates the frame type to the latest draft (-04)

deweerdt · 2018-06-09T23:53:58Z

@kazuho I've refreshed the PR to the latest master, as well as added test coverage.

Since this is now RFC 8336 and there is Firefox support, i believe the PR should be considered for merging.

kazuho · 2018-06-12T06:30:36Z

Thank you for working on this issue and keeping it alive.

ORIGIN frame

34d5380

This introduces a new option: `http2-origin-frame`. It can be either a scalar or a sequence. When this option is sent, H2O sends an ORIGIN frame as described here: https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-origin-frame.md

deweerdt added 2 commits February 13, 2017 15:59

ORIGIN frame

d1459ee

Move the config logic under the ssl listener config

Fix example compile

1194084

deweerdt force-pushed the origin-frame branch from 220e393 to 1194084 Compare February 14, 2017 00:18

kazuho reviewed Feb 14, 2017

View reviewed changes

deweerdt added 2 commits February 14, 2017 08:39

Remove the ssl struct from accept_ctx

6904ed9

Factorize the http2_origin_frame building code

d6e1850

kazuho reviewed Feb 15, 2017

View reviewed changes

Factorize build_http2_origin_frame callers code better

42c8fdd

kazuho added enhancement http2 parked labels Feb 22, 2017

deweerdt added 2 commits October 20, 2017 19:07

Merge remote-tracking branch 'origin/master' into HEAD

955aa6b

draft-ietf-httpbis-origin-frame-04

3b749c0

> The ORIGIN frame type is 0xc (decimal 12)

kazuho added this to the v2.3 milestone Jan 15, 2018

ConnorKrammer mentioned this pull request May 17, 2018

Cross Origin Server Push #1284

Open

deweerdt force-pushed the origin-frame branch from 97b8d52 to 3b749c0 Compare June 9, 2018 23:10

deweerdt added 3 commits June 9, 2018 16:17

Merge commit 'upstream/master' into deweerdt/origin-frame

9936c50

Add test coverage for the origin frame

7112c45

Add wildcart certificates

85e6438

clang format

e534f4c

kazuho merged commit 6d082a5 into h2o:master Jun 12, 2018

ORIGIN frame #1199

ORIGIN frame #1199

Uh oh!

Conversation

deweerdt commented Feb 12, 2017

Uh oh!

kazuho commented Feb 13, 2017

Uh oh!

deweerdt commented Feb 14, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kazuho left a comment

Choose a reason for hiding this comment

Uh oh!

kazuho Feb 14, 2017

Choose a reason for hiding this comment

Uh oh!

kazuho Feb 14, 2017

Choose a reason for hiding this comment

Uh oh!

deweerdt Feb 14, 2017

Choose a reason for hiding this comment

Uh oh!

kazuho Feb 14, 2017

Choose a reason for hiding this comment

Uh oh!

deweerdt commented Feb 14, 2017

Uh oh!

kazuho Feb 15, 2017

Choose a reason for hiding this comment

Uh oh!

deweerdt commented Feb 16, 2017

Uh oh!

kazuho commented Feb 22, 2017

Uh oh!

deweerdt commented Oct 20, 2017

Uh oh!

deweerdt commented Jun 9, 2018

Uh oh!

kazuho commented Jun 12, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

deweerdt commented Feb 14, 2017 •

edited

Loading