Release 0.6.5 ( Laurel )

[digitalextremist]

This upcoming release is being started with @kenichi's HTTP/2 update as a prompting.

[digitalextremist]

@kenichi have you worked out any HTTP/2 specific tests yet by chance?

[digitalextremist]

@kenichi this depends on Ruby 2.0+ syntax ... that's a pretty big decision. We may want to detect 2.0 and only include this if it's there... on a Gemfile level as well as in Reel

[kenichi]

@digitalextremist the http-2 gem requires ruby 2.0+ syntax? i didn't see a version req in the gemspec... i probably did put some 2.x hash syntax in my commit... if that's what you mean, i can fix that. obvs, i'm still learning about http/2 and what it entails. no tests yet, i was just seeing if it would work at all. there are some issues possibly with the http-2 gem still:

igrigorik/http-2#33

This one works with chrome tho, i believe because the "h2" during TLS:

https://gist.github.com/kenichi/cbc5745809966986cc87

I'm looking more into the RFC and the various other servers that implement like nghttp etc. See also:

• https://gist.github.com/tenderlove/6eccbaf4ee89838b7944
• https://github.com/tenderlove/ds9
• https://twitter.com/kenichi_pdx/status/618186117762781184
• https://github.com/bradfitz/http2

[digitalextremist]

@kenichi yeah, what I saw was hash syntax, the ** glitter. I think it's great, but I know for a fact the current syntax is largely why Angelo for example isn't being deployed more, which is a shame. I will dig into the links when I can and come talk to you about some ideas. If we can cooperate on some changes, I think we can bring Reel up to 1.0 alongside Celluloid smoothly. I invited you to Celluloid in a read capacity on reel, reel-rack, and celluloid-io -- but as an official contributor -- as a path to more, like reel-core /cc: @tarcieri

[kenichi]

@digitalextremist 👍

[kenichi]

Take a look at the latest commit to my branch, and perhaps if http-2's use of new syntax is undesirable, maybe ds9 as a wrapper for nghttp is a good alternative. I'd like to chat more about reel's current structure, Reel::Stream, etc. Things like breaking out of the each_request loop feel super hacky.

[igrigorik]

@kenichi what's the issue with http-2's syntax? If its anything we can fix, lmk.

[kenichi]

@igrigorik i think the issue is that reel would like to maintain 1.9 compat. apart from 2.x syntax, is there anything else in http-2 that would break that? also, i know the examples don't support upgrade, but are there plans to support the upgrade response stream in http-2 itself? i had to do some not great things to make it work in reel:

reel/lib/reel/connection/http_2.rb

Lines 53 to 83 in 5adabb0

	# handle HTTP/1.1 Upgrade request with HTTP2-Settings header
	#
	unless settings.empty?
	debug "101 upgrading with HTTP2-Settings: #{settings.inspect}"
	@socket.write UPGRADE_RESPONSE
	s[:connection] = @http2
	# stream 1 is response to upgraded request
	# https://tools.ietf.org/html/rfc7540#section-3.2
	# TODO add upgrade handling to http-2
	#
	s[:stream] = @http2.new_stream
	s[:stream].instance_variable_set :@id, 1
	s[:stream].instance_variable_set :@state, :half_closed_remote
	# The first HTTP/2 frame sent by the server MUST be a server connection
	# preface (Section 3.5) consisting of a SETTINGS frame (Section 6.5).
	# https://tools.ietf.org/html/rfc7540#section-3.2
	#
	@http2.settings settings
	# TODO add upgrade handling to HTTP2::Server
	@http2.instance_variable_set :@state, :connected
	# the HTTP/1 style request is supposed to be used as the initial
	# state of stream:1... TODO still trying to figure this out
	#
	HTTP2.on[:stream][s]
	end

reel/lib/reel/request/info.rb

Lines 29 to 43 in 5adabb0

	def http2_request?
	headers[UPGRADE] && headers[UPGRADE].downcase == H2C
	end
	def http2_settings
	settings = []
	h2s = ::HTTP2::Buffer.new Base64.decode64 headers[HTTP2_SETTINGS]
	(h2s.length / 6).times do
	id = h2s.read(2).unpack(UINT16).first
	val = h2s.read_uint32
	name, _ = ::HTTP2::Framer::DEFINED_SETTINGS.find {|_name,v| v == id}
	settings << [name, val] if name
	end
	Hash[settings]
	end

[tarcieri]

I'd be fine with ditching 1.9 support. It's EOL, and JRuby 9000 will be shipping soon I hope hope hope! /cc @headius

[igrigorik]

@tarcieri @kenichi if dropping 1.9 is an option, then a hearty +1 to that.

Re, h2c support: yeah, I think that's reasonable to support in core. That said, I would like nudge everyone away from plaintext and towards secure transports.. I don't think Tony will disagree with that either :)

[tarcieri]

@igrigorik I'd suggest waiting for the JRuby 9000 release, then immediately dropping 1.9 support when it's GA

[igrigorik]

@tarcieri makes sense. Based on stated roadmap, it sounds like it'll be out "soon"? If we think it's something that's ~months away (not years), then I think that's a reasonable thing to block on.

[headius]

Next week! But don't tell anyone!

[tarcieri]

@headius I'm sure your public github comment will be kept in the highest confidence

[tarcieri]

Ok, well JRuby 9000 is out. I say we deprecate 1.9 support in the next release.

[digitalextremist]

Ticketed that, and will start moving the last few 1.9 dependents I am aware of while removing support.

[igrigorik]

👍

[tarcieri]

Cleaning house on these