

Go language's HTTP/2 demo and interop server - Lealen
https://http2.golang.org/

======
alexandern
Nice to see more and more implementations popping up. You can track the
development of HTTP/2 servers and clients over at
[https://github.com/http2/http2-spec/wiki/Implementations](https://github.com/http2/http2-spec/wiki/Implementations).

------
nnx
Pretty awesome. Does this library also support backward compat with SPDY 3.x?
(which isn't yet in the standard lib either)

~~~
nnx
Just checked, nope. TLS NPN does not advertise SPDY 3.x support.

------
htor
Exciting to see this standard being built and also very useful to see the
performance comparisons with HTTP/1 communication.

I wonder if HTTP/2 will change the way we develop websites now that it's
cheaper to load resources?

------
wvh
I enabled spdy4 in Chromium on Debian "unstable" but the website doesn't seem
to think it's on. What are we supposed to see?

------
drsintoma
what are the main differences between SPDY 4 and 3.1?

~~~
latch
This recent post and accompanying comments might help:
[https://news.ycombinator.com/item?id=8549348](https://news.ycombinator.com/item?id=8549348)

------
hobarrera
So, go fails to work on IPv6 environments, but they've gone through the effort
to actually implement http2? Looks like their priorities are all messed up.
:-/

~~~
tptacek
What's the Golang IPv6 problem?

(It does not seem weird to me that they'd prioritize functionality that
everyone with a modern browser will be able to use versus functionality that
quite possibly won't be useful to most Internet users ever.)

~~~
chimeracoder
> versus functionality that quite possibly won't be useful to most Internet
> users ever.)

You don't think that IPv6 is ever going to gain widespread adoption?

Given how much of the US uses Comcast as their residential ISP alone, and how
aggressively Comcast has been rolling out IPv6, I think we're near a tipping
point[0].

Enterprise/business use will take much longer, but that's to be expected, as
rollout for residential use has far fewer potential problems.

(For the record, I did not downvote you).

[0]
[http://www.google.com/intl/en/ipv6/statistics.html](http://www.google.com/intl/en/ipv6/statistics.html)

~~~
tptacek
Nope, I don't. (I'm less certain of this than I am about DNSSEC, but in the
same ballpark on both).

I think this is, for what it's worth, a good thing. IP belongs to the telcos.
The failure of IPv6 adoption (and it's been failing for a long time) is
forcing us into building overlays on top of ephemeral/translated IPv4
endpoints, which has the effect of pushing responsibilities back towards the
endpoints and away from opaque middleboxes.

~~~
zurn
This may be an interesting contrarian position to argue, but come on. The NAT
situation takes us toward end-to-end and away from middleboxes? In real life
it's more likely for communities and systems to bow than rebound in response
to strong chilling effects.

~~~
tptacek
This isn't a contrarian position. The only VC-backed startup I founded had
this as a premise. I don't just think it's the right architectural plan for
the Internet. I think it's what's going to happen.

