Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

4.
1 year ago..
● “How happy we can become with H2O/mruby”
○ YAPC::Kansai
○ https://www.slideshare.net/ichitonagata/h2o-x-mruby-72949986
● Talked about the potential of mruby in web servers
● I was searching the opportunity to introduce H2O/mruby
○ in large scale service..

10.
Example 1: Bug of Size Restriction
● Converting the size of images with the URL like:
○ https://img.roomclip.jp/v1/{{dst}}/img_{{src}}/deadbeaf.jpg
● But They wanted to set an upper bound of {{dst}}

12.
● There may be 7 pre-downsized original images
○ 90, 180, 320, 640, 750, 1242, 1536
○ in local cache and S3
● We should select the minimum original image
○ If 100 is requested, 180 should be elected
Example 2: Wasting Use of Original Images

44.
mruby-rack
● https://github.com/i110/mruby-rack
● mruby port of Rack. Included in 2.3.0b1 released today!!
● Run original Rack specs
● It was harder than I expected..
○ Subtle syntax differences between mruby and CRuby..
○ lack of many core modules..

52.
Early-Data header and 425 Too Early
● TLS 1.3 introduces Early-data
○ application data sent before TLS handshake completes
○ can be replayed by an attacker, since it is sent at 0-RTT
● replay isn't an issue for idempotent requests, but...
○ in reality, only the webapp knows if a request has idempotency
● webapp behind a reverse proxy can't tell if the request
was sent using Early-data
● Solution:
○ reverse proxies add Early-Data: 1 to requests received in 0-RTT
○ webapps can refuse the request for later replay using 425

54.
Feb 2016
● how should an app. server notify the H2 server to start
pushing assets before generating the response?
○ some webapps emit 200 OK then builds their response
○ but that approach does not work well when other status codes
are involved (e.g. 302)
● let's use 100-continue + link: rel-preload
○ implemented in H2O, nghttp2
○ should we standardize the feature?

55.
The pushback
● changing the semantics of 100-continue is a hack
● we might want to have a new 1xx status code, but…
○ how does a final response update the headers sent using 1xx?

56.
Nov 2016
● how about considering the headers of 1xx as "hints"?
○ fits nicely with the current generic definition of 1xx status codes
■ i.e. that unknown 1xx can be "ignored"
○ retransmitting same header twice is a non-issue in H2 thanks to
HPACK
● response at IETF 97: "let's do that!"
○ becomes a Working Group document (Dec 2017)

57.
What about clients that cannot handle 1xx?
● "we cannot break the web"
● "let buggy clients fail miserably. Protocol development
should not be hindered by them"
● "how about negotiating the use?"
○ "header-based negotiation is end-to-end. But proxies in the
middle might be buggy"
● conclusion:
○ just warn that use of 103 might have issues with H1 clients
○ no worries about h2 over tls

58.
Existing clients might accept cookies in 1xx
● that would contradict with the concept of 103 being
purely "hints"
● the choice: define 103 as something that
○ a) "can be considered as hints"
○ b) "is hints"
● conclusion: b
○ let's dismiss the theoretical existence of such clients
○ having a clear definition will be better in the long run

61.
How to evaluate multiple 103 responses?
● two interpretations:
○ a) the following hints replace the preceding ones
○ b) each hints is individual
● conclusion: b
○ each source of the hints might have different policy on what to
send as hints
■ e.g. a proxy might send hints based on machine learning, while the
origin might send hints for js, css based on written rules
■ sending each signal as-is will give client more information to decide

64.
Will 103 and H2 server push coexist?
● they can coexist 103
○ as hints sent to h2 server
○ server push is 1-RTT faster
■ but has issues, especially without Cache-Digests
● some hope 103 to kill push
○ because it's simpler
● API in the webapp will be indifferent
○ e.g. rack.early_hints

65.
Lessons Learned
● ossification is an issue
○ buggy clients
○ new protocols will grease and obfuscate
■ occasionally send dummy extensions in any extension point that
exists
■ make information unobservable by middleboxes
● e.g. packet number encryption in QUIC
● we will see forgotten features of HTTP being used
○ informational response trailers what's next?

67.
Supporting complex interaction with a simple API
● HTTP is becoming more and more complex
○ rationale: for speed and new use-cases
○ H2 push, early-hints, 425, Server-Timing, QUIC, WebSockets on
H2, ...
● provide simple, programmable API for using the features
○ mruby & Rack to the rescue!