Is std.http insecure?

Explain
1

in http.zig’s README.md:
“std.http.Server is very slow and assumes well-behaved clients.”

are there any known vulnerabilities? when is it planned to be production ready?

2

I think if a project wants to make such claims, it should link to open issues.

I don’t know when this text was created, but here’s a brief timeline of std.http:

  1. Initial version of some random http APIs contributed
  2. I deleted most of it because I didn’t like it
  3. Initial version of http.Client and http.Server contributed
  4. I didn’t like either one. I rewrote Server but didn’t have time to rewrite Client yet
  5. Now I am rewriting all of std.http

Once I’m done, I’ll be happy to take responsibility for the performance and production-readiness of this code.

13 Likes
Future prospects of Web Development with Zig?
3

I’ll note that, despite @andrewrk response, I’m not sure a production grade HTTP server is really at home in a standard library. Depends on what is meant by “production grade”.

3 Likes
4

To me, “production grade” means high confidence in the absence of bugs, particularly those which allow remote code execution, but also lesser ones such as crashes and the ability of one client to compromise performance for other clients.

I think that will be accomplished once we have integrated fuzz testing and have made some nice fuzz tests that check the client and server against each other.

11 Likes
5

you guys are putting immense work on the ziglang project, and so I want to thank you for making good stuff all the time, and with the new Io interface I think achieving good tests like jetzig’s would be better, simpler and faster! (also, I thought you might like seeing someone using zig’s tests in a kinda-of unique way)

and for the statement: it looks like it’s an old library, maybe even before ‘1.’, the initial version.

1 Like
6

I would disagree, looking at how succesful Go’s was.

1 Like
7

I think the batteries included approach is highly comendable these days, especially for something as core as http. It is one of the reasons I still reach for golang for anything io/network related.

There is nothing worse than 50+ different 3rd party implementaions of standard library stuff, and dozens of includes for supporting features.

It almost feels like package managers should be limited to a dependency graph depth of one, or just not provided :slight_smile: This used to drive me mad in Java, even with it’s comprehensive std lib, dozens of dependencies for basic stuff like logging, date&time etc.

Although I’m a bit of an extreme data point, since I prefer to build with zero external dependencies these days. Quite easy coming from Golang, and it maybe comes down to systems programming vs application development.

But I think it is also the new-world trust issues. I’d much rather have my trust circle limited to the experts behind the language I’m using.

4 Likes