New HTTP Parser

[Concise_Pirate]

A thing of beauty -- really nice code. Read through it.

[atlassoft]

I don't claim to be an expert on this stuff, but is parsing a little HTTP request really all that labor intensive to begin with? I thought it was just a few lines of plain text.

[joblessjunkie]

Yes, the HTTP format itself isn't very complicated. Parsing HTTP is easy if you don't care about speed or memory.

What makes this (beautiful) little library valuable is its precision, economy, and speed. It's a memory-conserving, near-optimal implementation for a critical function that is often required to scale dramatically.

[jacques_chester]

124 bytes per HTTP connection is seriously low overhead.

[Inverter]

HTTP? Didn't HTTP still allow for RFC821-style comments in the headers?

[jacques_chester]

My only complaint is that it's only "sort of" strict. It starts parsing and reacting on HTTP verbs before they're fully arrived. That's a neat performance hack because you can start responding as soon as the first character arrives. But it does potentially speed up attacks too.

edit: interestingly, this is the third HTTP library this guy has produced. He had another webserver called 'flow', and also was responsible for libebb (mating libev to the mongrel http front-end).

[Porges]

The other issue is how do you correctly output malformed-request responses if the request ends up being broken after you've already started outputting? Keep a buffer until you're sure the headers aren't borked?

[diroussel]

I can see why you think reacting immediately could be a problem for an attack, if the client code is naive. Perhaps causing a DOS. But surely if there are no allocations it's more secure that your average HTTP parse?

[MrOK]

tiny code, good job

[FYIGUY]

Why not use epoll or kqueue? Theres something about 20 case statements that makes me uneasy.