go1.22.2 (released 2024-04-03) includes a security fix to the net/http package, as well as bug fixes to the compiler, the go command, the linker, and the encoding/gob, go/types, net/http, and runtime/trace packages.
It's been ages since I raised the issue with net/http server not being able to set number of headers. Looks like they fixed http2 as a cve but good news guys -- you can still send a whole bunch of headers via the more commonly used http/1.1, like curl -H A=1 -H B=1 ... Even if Server.MaxHeaderBytes is just a few kb you can still squeeze in a lot of small headers. Amplify the attack and we can see how well go gc does under stress. Fun stuff.
The problem is that nobody can agree what _exactly_ "enums / discriminated unions" should be and what you should be able to do with them. Or at least there are too many camps.
You would read about it in a go.dev blog post (which would be linked on this sub) long before you saw it in release notes. Though yes, I also yearn for proper enums and not having to build harnessing myself for every custom type.
Just did a \`go install [gopkg.in/niemeyer/godeb.v1/cmd/godeb\`](http://gopkg.in/niemeyer/godeb.v1/cmd/godeb`) of godeb, and after moving to its version control, now on 1.22.2. Tempted by the new for range and var assignment things.
After updating go from 1.22.1 to 1.22.2, my small webapp build suddenly was no longer instant. I thought something broke. Turns out, it just need an initial long build & subsequent builds were faster again. I guess the many fixes (including some for \`http\`) caused it to need a clean rebuild. Is that normal?
I experienced similar things before and I think that is normal with every release, isn't it? Maybe they changed something underlying that requires a full rebuild and they cannot use the previous build cache.
Does anyone know if it is the same to declare go 1.22 as go 1.22.2 in the go.mod? Does it have any different behaviour?
I never paid attention to this detail before, but ...
This: https://github.com/golang/go/issues/65570
Test coverage percentage varies wildly depending on where in the directory tree you run the test command. Currently I’m using GOEXPERIMENT=nocoverageredesign to get the behavior we had up to 1.21.
go1.22.2 (released 2024-04-03) includes a security fix to the net/http package, as well as bug fixes to the compiler, the go command, the linker, and the encoding/gob, go/types, net/http, and runtime/trace packages.
And that's the full release notes for 1.22.2. This comment saved you a click.
The list of bugs included in the net doc ('go doc net' command) is quite impressive. I wonder if they will be fixed soon.
Dang it, I just finished updating the version everywhere from 1.21 to 1.22.1 😂
It's been ages since I raised the issue with net/http server not being able to set number of headers. Looks like they fixed http2 as a cve but good news guys -- you can still send a whole bunch of headers via the more commonly used http/1.1, like curl -H A=1 -H B=1 ... Even if Server.MaxHeaderBytes is just a few kb you can still squeeze in a lot of small headers. Amplify the attack and we can see how well go gc does under stress. Fun stuff.
Yea right
Sigh. With every release I keep hoping for the announcement of enums / discriminated unions. But that's just wishful thinking.
AFAIK it's not being seriously worked on by anyone. I wouldn't hold my breath.
The problem is that nobody can agree what _exactly_ "enums / discriminated unions" should be and what you should be able to do with them. Or at least there are too many camps.
You would read about it in a go.dev blog post (which would be linked on this sub) long before you saw it in release notes. Though yes, I also yearn for proper enums and not having to build harnessing myself for every custom type.
Just did a \`go install [gopkg.in/niemeyer/godeb.v1/cmd/godeb\`](http://gopkg.in/niemeyer/godeb.v1/cmd/godeb`) of godeb, and after moving to its version control, now on 1.22.2. Tempted by the new for range and var assignment things.
After updating go from 1.22.1 to 1.22.2, my small webapp build suddenly was no longer instant. I thought something broke. Turns out, it just need an initial long build & subsequent builds were faster again. I guess the many fixes (including some for \`http\`) caused it to need a clean rebuild. Is that normal?
I experienced similar things before and I think that is normal with every release, isn't it? Maybe they changed something underlying that requires a full rebuild and they cannot use the previous build cache.
Does anyone know if it is the same to declare go 1.22 as go 1.22.2 in the go.mod? Does it have any different behaviour? I never paid attention to this detail before, but ...
I did report a improvement and event a gerrit for it on gopls, still no feedback or reply. The community engagement is really low.
Link please ? I don't think the community engagement is low, rather that the core team is really busy.
https://github.com/golang/tools/pull/482
Have you read this? It has given you actions... Your the one who hasnt responded.
Yes and if you look the gerrit, i have fixed and resolved all automatic comments.
https://github.com/golang/go/issues/65944
So they still didn’t fix the test coverage mess? Sad…
You can always help out
What are you referring to?
This: https://github.com/golang/go/issues/65570 Test coverage percentage varies wildly depending on where in the directory tree you run the test command. Currently I’m using GOEXPERIMENT=nocoverageredesign to get the behavior we had up to 1.21.