Re:Let’s Build a Web Server, Part 3
by falcolas on Monday August 03, 2015 @10:48AM
(#9996236)
This is actually something that breaks my heart a bit, because this might not work (or be heavily deprecated) at some point in the near future.
If, or when, HTTP/2 is the only protocol available suddenly you can't just return a string with a few newlines and have it mean something. Instead, you have to send a connection preface, then start building and sending frames of data in specific orders with specific binary packing formats.
Length, 24 bits. Type, 8. Flags, 8, an ignored reserved bit, an identifier which must be odd (except when it must be even), padding lengths, and finally a payload (don't forget that padding!)
I know there's value in moving to HTTP/2, but it's yet another stumbling block in the path to understanding how our environments work. The straw hasn't fractured the camel's back yet, but I imagine the camel is wishing it would all just end.
Maybe this tutorial just needs a part 4, how to respond properly to HTTP/2 requests.
Re:Let’s Build a Web Server, Part 3
by Obi_Juan_Kenobi on Monday August 03, 2015 @06:25PM
(#10000331)
This is fantastic; I'm just learning about TCP/IP and websockets and find the whole subject very difficult to get through. There's a lot of magic-looking numbers and weird standards that don't make sense without context. I'd find myself spending a lot of time hunting things down, which while effective, is difficult to do while maintaining focus.
There's so much wonderful context and 'why' to this series; it's honestly a bit of a revelation. Even if I don't care to learn about e.g. UNIX details, that little peak behind the scenes at the right time really helps create a coherent mental model.
Re:Let’s Build a Web Server, Part 3
by jlees on Monday August 03, 2015 @01:05PM
(#9997775)
I used Part 1 of this tutorial as the basis for a lecture in a full stack web development class. Fantastic resource, and while my students praised the content for helping them figure the "why" as well as the "how", the praise really belongs to Ruslan.
If, or when, HTTP/2 is the only protocol available suddenly you can't just return a string with a few newlines and have it mean something. Instead, you have to send a connection preface, then start building and sending frames of data in specific orders with specific binary packing formats.
Length, 24 bits. Type, 8. Flags, 8, an ignored reserved bit, an identifier which must be odd (except when it must be even), padding lengths, and finally a payload (don't forget that padding!)
I know there's value in moving to HTTP/2, but it's yet another stumbling block in the path to understanding how our environments work. The straw hasn't fractured the camel's back yet, but I imagine the camel is wishing it would all just end.
Maybe this tutorial just needs a part 4, how to respond properly to HTTP/2 requests.
There's so much wonderful context and 'why' to this series; it's honestly a bit of a revelation. Even if I don't care to learn about e.g. UNIX details, that little peak behind the scenes at the right time really helps create a coherent mental model.