🚫 Go team says no, what is HTTP error 407, and do you need DI frameworks

This show was supported by you, our listener. Stick around to live for the news to hear more about that. This is Cup and Go for 06/06/2025 or 06/07/2025. We're recording on the sixth. Keep up to

date with the important happenings in

the Go community in about fifteen minutes per week. I'm Jonathan Hall. And I'm Shyne Hachman. Hey, Shayne.

You hesitated there for a Were you about to say I'm Shay Nehhmad?

I was about to.

I saw it. How you doing, man?

I'm alright. Getting ready to travel. I won't be here next week for the show because I'll be in Brighton in The UK.

Oh my god. So Yeah. If you wanna replace Jonathan on next week's recording slot, come talk to us at the Copago channel. If you already did it in the past, wait for a We wanna try to get more friends of the show on the show.

And if you're gonna be in Brighton, hit me up and we can have a drink. Or Amsterdam. Right? Yeah. I'll be in Amsterdam one one day two nights, one day after the after that.

Cool. Cool. Cool. This week, I wanna kick things off with the new minor release. Go one twenty four point four and Go one twenty three point ten have been released, and they include three security fixes.

Oh.

So do you know what is the authorization header on, on HTTP request, like, we would use it?

Yeah. That's where you would, like, pass in your auth token or whatever. Right? You say authorization bearer and then a bunch of random seemingly random digits that represent a JWT or something. Mhmm.

What about, like, in general, you have tons of ways to do it. You usually use the authorization header. Right? Yeah. You could use, JWT. You could use basic auth, blah blah blah. Almost everybody who's done a web app at some point probably had to implement it either themselves or integrate with a party, like, provider. Right? Now let me ask you a slightly harder question.

Mhmm.

If you implemented this, you probably know what a four zero one error is in HTTP. Right? Yeah. What's a 401?

I never remember 401 versus 403.

401 is unauthorized.

Unauthorized. Yeah. And 403 is Forbidden. Forbidden. Yeah. Mhmm. So unauthorized means that, like, you have not provided meaningful or correct authorization token of some sort. You haven't authenticated. Right?

Yes. And now I'm gonna raise the stakes one level higher to get to the actual problem in this in this security release. What is 407? Do you remember? No. Okay. So they also forgot about it when they implemented NetHCP. Basically, in the same way you have authorization, you have a header called proxy authenticate. There's a weird ass thing in HTTP that proxies are like a part of the protocol in some sense Mhmm. Instead of being like just an extra layer.

Okay. Sure. Yeah.

Because you don't wanna like, you redirect the request from cross origin, right, from a to b, and you wanna make sure that you wanna strip these sensitive headers. Why? Because if you redirect to a different site and you keep these headers on the request, I could just redirect you to, like, my malicious site Mhmm. It it by just doing some XSS or whatever on a popular web site or phishing or whatever. Mhmm.

Mhmm. Makes sense.

They did it for authorization, w w w authenticate, cookie and cookie two, and they just sort of forgot. Proxy authentication or proxy authenticate. If you look at the actual change with and and I'll put the specific commit. We don't usually do this, but I'll put the specific commit in the show notes. It's like the easiest I could read the commit out loud.

Right.

So it's like part of the fetch standard. It's part of HP standard. It's, like, written all over the place. Just in every place you see, the normal authorization thing is written, and then in, an extra paragraph, it's also, oh, don't forget, also, proxy. So they did forget, and it was reported by, I hope I'm saying this correctly, Takeshi Kaneko, from GMO Cybersecurity by Leria, something like that, Incorporated.

should

like broadly upgrade.

I've done a lot with proxies. I don't think I've ever used proxy off that I not in Go anyway. I may have in a previous lifetime.

It might have happened like without you knowing it. Right?

Yeah. That's very possible.

EngineX taking care of it for taking care of it for you or something. So that's the one.

Alright. What else?

The security fix is also super cool. And it's one of your favorite topics, Linux against Windows. Right? Long time listener of the show, will know that Jonathan uses Linux, which is why it took him, like, three months to set up his home network when he moved to his new That

is not why, but okay.

It's in the same culture category. But there is, there was just a behavior that was inconsistent between Linux and Windows, when you try to, create a, like, a file handle. Let me I'll describe the scenario and you'll tell me what do you think should be the behavior. Right? So I'm calling open file Mhmm. On with, like, create. I want to create a new file. Right?

Alright.

And the target path is a symlink, like a dangling symlink.

So there's is a symlink that that's on the disk, but it doesn't point to anything and you're trying

to create Like a shortcut. Again, in in Windows terms, like a shortcut, but the the underlying thing behind the shortcut doesn't exist.

Alright. And

now I'm trying create

that file even though it already exists as a symlink. Okay.

What should I do? What what should happen? What would you want to happen as, like, a developer?

I would either want to overwrite that file or give an error because it already exists depending on which mode I'm using. Right?

So it's with ocreate and oexcel.

So that would I would expect that to give an error.

So there's an inconsistent behavior between these two systems. In the proposal, you can even see, like, they included a test that shows, like, this test will pass on Linux and fail on Windows, which is like, you know, when you call OS open file, you want to see an error. So if you create a symlink to something that does not exist, it should fail when you try to create that to, like, open file and create that file. When I looked into it, the one interesting thing I found is the hacking lab, like, behind it. I'm I'm not sure what type of organization it is specifically.

I hope I'm pronouncing your name

correctly, Joon Young Park. They're just one of the PhD students in this group, and it looks like there's a lot of people here, which I I I found it pretty cool. Like, you can see the the people behind it, and they're, like, a bunch of students in in South Korea. So so if you wanna follow them or or or, like, check it out, you go to kaishacking.github.io and, like, see all of their publications, all their CVs. They do some really cool stuff.

And of course, the one you didn't go into detail on is related to x five zero nine certificates. If you're using that, upgrade too, even though we're not talking about the details there.

Yeah. So a cool, like, security release. I liked it. I like it when the security stuff is this thing I can pretend I understand. Awesome.

Next up. So anybody who follows Go on social media probably already knows this has happened. But the Go team, specifically Robert Grasmere, has published a post about this error handling in Go. TLDR, we've been talking about improving error handling for years with dozens or hundreds, possibly thousands of proposals directly or indirectly related to it and cannot get anywhere close to consensus. So Go team has decided for the foreseeable future, we will stop pursuing syntactic language changes for error handling.

happy to like, anything that helps focus. Yeah. Is a good idea. Like, if the team can focus on on things that the whole point of of Go proposal, Go discussion, Go whatever is to drive action. Right? Mhmm. These discussions are not action. Action is code that goes it gets committed to go and gets released in a version. Yep. Anything else is is bureaucracy.

Fair enough.

Code or documentation or talks or education or funds, like, these are actions. But just talking about, the proposal itself, while it is useful, it's only useful in the sense that it will lead to action. I'm a 100% convinced that talking about error handling in Go will not lead to action at this point. So I'm really glad to see them closing the lid on it. I feel the same way about the like YAML.

is good or not. Yeah.

Putting my opinion back in, I think error handling is fine. Like, I don't get what it's fine. Sure. It's a little verbose. Whatever. Who cares? Look, at the moment you get used to this code, you read through it pretty fast anyway.

Yeah. I'm I'm reminded I know not everybody listening here, of course, follows the US Supreme Court. And And I'm not talking about a specific case, but whenever they often rule on something other than the actual case, right? Like, I don't know if Bob should have been allowed to do this thing to Alice, but he wasn't allowed to sue her for this reason, that sort of thing. And this is kind of like that.

Yeah. Now you know it's set in place. So I think it's called, like, a legal precedent or something like that.

That's a separate con concept. Yeah.

Oh, okay. Never mind. Will say, I think that at this point, people who are, like, unhappy with the error handling to the point that really, really bothers them are are gonna be less and less. Because I don't know about you, but the more I use like Copilot and this exactly the sort of boilerplate that I'm happy to see when I'm debugging, right? Because I can read the code line by line and there's like no magic.

All right. Well, enough about that. We're not gonna talk about error handling anymore ever on this show since it's been closed. We probably will talk about it on the show, but

Go team does not allow it.

So we have one more story to talk about, a blog post before we jump into the break and the lightning round. This blog post comes from Ottawa in Delaware. It is called You Probably Don't Need a DI Framework. And I have to say I was very happy to read this, not because of the content per se or the opinion it expresses, but because it explained to me what a DI framework does in Go. I've been wondering this for a long time because I've never used one.

My thoughts on it is it's very pragmatic. I like it a lot. Coming from both lower level and higher level languages, like my experience before starting Go was either like c plus plus, like Python, and c sharp. Mhmm. Dependency injection was a big thing.

Mhmm.

It's great for tests. It worked really well for me. I'm really happy to see, like, someone who's working at, like, a real company. Red one is, like, at Walt, which is a huge, like, it's like DoorDash. I used to use it all the time as well, saying basically, yeah, Shay, you were right.

So I do think it's worth pointing out the problem that DI frameworks are sensibly meant to solve, right? And that is that you sometimes end up with these constructors that take five or 10 or 20 or 100 different arguments for all the different dependencies they have. Right. And that can look ugly. And by using a dependency injector framework, maybe pass one thing in that kind of magically handles all that for you.

It just adds more confusion than what it's worth. Don't think it is of zero value. It's nice. I just think that the cost it introduces is much higher than the value. Sure. Even if you have a ton of modules. And by the way, like, if you have a thing, like a new call that that has a million dependencies. Right?

Mhmm.

Let's say not a million. Let's say re reasonably. Right? It's the I don't know. Your main whatever module. Right? And it depends on the database module, and the database module depends on the configuration module, and the configuration module depends on the logger module. Mhmm. Right? And it also depends on the, I don't know, widget service, and the widget service depends also on the configuration module, blah blah blah, etcetera, etcetera.

Mhmm.

And you're like, oh my god. I'm calling I'm passing in the logger thing a million times. Wouldn't you prefer to see it and be like, oh, maybe it's better for me to just make the logger, like, global static and and not have all these dependencies. If you don't if you have a DI framework, it's not like that Yeah. Architectural nonsense doesn't exist.

Yeah. Constructors are the are the one exception I have to the the general rule of like no more than four arguments to a function or whatever number you choose. Right? I don't follow that religiously when it comes to constructors because I want to see just like you're saying, I want to see the complexity that my constructor is taking on. And sometimes I refactor that.

Yeah, the graph is too dense. Yeah. I I will say my rule is the same, but that all constructors must be either in bootstrap.go or be of something that is actually in the in business value is dynamic, like loading a real plugin, like loading a new DLL into Notepad plus plus or something. But I I really don't wanna call new on, like, a real module. I'm not talking about, like, a a just a data transfer object.

Yep. Absolutely.

So I I love I love this blog post. Great stuff, Radwan.

I'm curious if anybody listening disagrees. If if you love your DI framework, let us know why, which one you're using and what problem solves for you and why you love it. We'd love to hear about that on our Slack channel, which I think is a great segue into our little break where we talk about our Slack channel. So if you don't know, we have a Slack channel. It's on the Gopher Slack or Cup A Go.

It's a cool channel. It's kind of a fun place. I accidentally incited an AI related discussion, so maybe wait a day, and then it'll become like AI free zone again.

Well, you're in San Francisco where apparently they believe in AI a 110%.

So I mean, I I took a driverless car to my to my meetup, so I I it's hard to argue with it, you know. There's something in the something in the water. I do wanna shout out, like you said at the beginning of the show, the show is supported by the listeners via Patreon. So two things. One, Patreon reminded me to remind you, don't use the iOS app because it takes like a cut.

We don't pay to advertise, so if you could share this show with your friends, colleagues, fellow students, leave a review, leave a rating, that is all that we need to get this show known about. Our listenership is growing. We had a record breaking month last month as far as number of We love that. Keep up the good work. Keep keep sharing the show.

And one final reminder, if you want to replace Jonathan next week and host the show with me, talk to me on the Slack. I don't wanna do the episode alone, basically, is it? Alright. Let's do a quick lightning round.

Let's do a lightning round.

Lightning round.

on the lightning round, the Stack Overflow developer survey this year is open.

Stack Overflow? I thought it's dead.

Yeah, but I think it might be. That's a shame actually.

I have

to say I did this survey and you can imagine it's all about AI and how do you use AI and how would you like Stack Overflow to be improved with AI? And I have to say, I think half of these questions are written by AI because they don't make sense and there's grammatical errors and like logical errors and all sorts of ridiculous nonsense. I have to say, I wasn't really impressed with the survey this year. But I thought I'd

tell you I'll tell you another thing, and I'm putting this in in our channel right now, like our internal host channel. I just opened Stack Overflow, and it got like, oops, something bad happened, error. You know what? I'll skip it this year, I think.

Anyway, when the results are out, we will, of course, go digging through the results to see anything relevant to go, and we'll talk about that in a in a few weeks or months whenever that's around.

If there's something relevant.

If there's something relevant.

It might have faded into irrelevance, this site, unfortunately. My Lightning Round thing is a cool cool idea. I haven't tried using it yet. I don't think I will, but I really like it. It's called Gitbug. Where do you you are like a contractor. Right? You do work with clients for them, whatever. Where do you like tracking bugs the most? I assume it's not Jira, even though you had to do Definitely

not Jira. Linear maybe? I usually prefer whatever is tied to the source control we're using. So it's usually GitHub issues or GitLab issues.

So you might like Git bug, which is storing the bugs in, like, inside Git in in the dot Git directory. So you manage issues, users, and comments, like, directly from within the repo. So it's versioned, it's, like, clutter free, it's distributed. Right? So it's, like, on everybody's machine.

Interesting. Yeah. I'll have to check it out. I'm curious how it would handle, like, conflicts and stuff,

but And videos. Like, half of the bugs I I put for the front end, I wanna say team guy at work Mhmm. Is an advantage of working in a small startup. Include like a small video of me like, hey, this is how it messes up. Yeah. It is interesting. I I like the I like the concept. Might try it.

Cool. Last today on the lightning round, friend of the show and previous cohost, so I guess he's not eligible this time. Jamie Tanner has done a blog post about looking back for last year about API cogen. We had him on the show as an interviewee also talking about OpenAPI Codegen.

Sure, yeah. So as you mentioned, I am one of the maintainers of a Go command line tool and library called OAPI Codegen. OAPI Codegen transforms OpenAPI specifications.

If you are a user or potential user of OAPI Codegen, this might be relevant to you. It sort of gives us, like I said, a summary of the changes over the last year, which were versions released. And of course, looking forward into the future, they're looking for some sponsors. Jamie would love to spend some dedicated time on this to implement new features that are not there right now.

Yeah. Specifically OpenAPI 3.1, like supporting the new version of OpenAPI. Generally, I think this blog post, this like post on the GitHub announcements and his blog post on his site. Just give the air of this is like a serious thing, like serious production thing, which is very cool.

So that's it. Check it out. We will be back together in two weeks time next week. I hope you have fun without me.

Alright. Program exited. Program exited. Goodbye.