Go language's HTTP/2 demo and interop server(http2.golang.org)
http2.golang.org
Go language's HTTP/2 demo and interop server
https://http2.golang.org/
7 comments
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.
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?
I wonder if HTTP/2 will change the way we develop websites now that it's cheaper to load resources?
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?
what are the main differences between SPDY 4 and 3.1?
This recent post and accompanying comments might help:
https://news.ycombinator.com/item?id=8549348
dariopy(4)
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. :-/
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.)
(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.)
https://code.google.com/p/go/issues/detail?id=8124
Lack of IPv6 support means that some people have no network capabilities when using go-based apps (eg: a critical, fatal bug). https is just a an enhancement.
critical bugs come before enhacements.
Lack of IPv6 support means that some people have no network capabilities when using go-based apps (eg: a critical, fatal bug). https is just a an enhancement.
critical bugs come before enhacements.
The thread you pointed to doesn't back up the broad statement you're trying to make about Golang, and, like most of the world, this is an issue I don't care about, so I disagree with your prioritization.
People on CLNP-only networks also have problems with Golang, despite the fact that Unix kernels do provide CLNP sockets.
People on CLNP-only networks also have problems with Golang, despite the fact that Unix kernels do provide CLNP sockets.
However, CLNP is not deployed by any major ISP. It's not gradually replacing IPv4 either.
A small percentage of users around the world have IPv6-only (+ some transition mechanism) connections and have no issues using the general internet. This number is continuosly growing, and will continue growing.
This issue will affect you inevitably, so I think it's extremely shortsighted to not-care about it.
A small percentage of users around the world have IPv6-only (+ some transition mechanism) connections and have no issues using the general internet. This number is continuosly growing, and will continue growing.
This issue will affect you inevitably, so I think it's extremely shortsighted to not-care about it.
> 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
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
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.
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.
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.
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.
It's probably useful to distinguish between "people with IPv6" and "people without IPv4" when discussing the realized utility of IPv6 support.
Indeed. The number of use users with no native IPv4 are probably a lot less than dual-stacked users, but inevitably, the amount of IPv6-only users will continue growing, given the current trend.
Why would you post this? Go has supported IPv6 since day one.
Supporting IPv6 and "working normally on IPv6 environemnts" are different things. As an end-user, go-apps don't work over IPv6 unless they're hardcoded to use only that:
https://code.google.com/p/go/issues/detail?id=8124
https://code.google.com/p/go/issues/detail?id=8124
net.Dial() really is terrible, but it's fairly easy to work around. Instead of passing a hostname to net.Dial(), you can call net.LookupHost(...) and iterate over the resulting IP addresses.
It sounds that it adds too much burden to developers to simply communicate to some host over HTTP. It sounds pretty hard to convince every single developer out there to replace net.Dial with that.
What are you talking about? The net package does support ipv6[0].
Also, while ipv6 is important, let's keep in mind that many hosting providers (including Amazon) still don't provide IPv6, and have no timeline for it either.
HTTP2 is at the application level, so it is useful immediately, without any change to existing infrastructure.
[0] http://golang.org/pkg/net/
Also, while ipv6 is important, let's keep in mind that many hosting providers (including Amazon) still don't provide IPv6, and have no timeline for it either.
HTTP2 is at the application level, so it is useful immediately, without any change to existing infrastructure.
[0] http://golang.org/pkg/net/
> Also, while ipv6 is important, let's keep in mind that many hosting providers (including Amazon) still don't provide IPv6, and have no timeline for it either.
There are transitional techniques, like NAT64 to connect to those hosts. Keep in mind that some ISPs only offer native IPv6, so lack of proper IPv6 support means go-apps become unusable.
There's IPv6 support, but things like `conn, err := net.Dial("tcp", "google.com:80")` fail on IPv6-only hosts, because only an IPv4 connection is attempted.
There are transitional techniques, like NAT64 to connect to those hosts. Keep in mind that some ISPs only offer native IPv6, so lack of proper IPv6 support means go-apps become unusable.
There's IPv6 support, but things like `conn, err := net.Dial("tcp", "google.com:80")` fail on IPv6-only hosts, because only an IPv4 connection is attempted.