Slashdot Mirror
HTTP: The Definitive Guide
OK, so I answered "C". I am going to make bold the claim that HTTP: The Definitive Guide, the long-awaited O'Reilly book on HTTP is ambitious enough in breadth and depth that if you answered "B," "C," or "D," you will find this book useful and informative. This is primarily due to clear organization of the book, as well as its friendly (even chummy) writing style.
Even if you are a technically-inclined sort from the Marketing department, and answered "A," you could get a good technical overview of the plumbing of the Web by skimming through this book; plus, having any O'Reilly book on the shelf in your cubicle would score you some street cred with the guys sitting over in Development -- this could be the one you've actually read. :-)
Breadth Unless you answered "D," HTTP is more complicated than you think. This is especially true if, as the authors of a good technical book should do (and these authors do), one spends some time touching on matters one level down (to TCP/IP, and other areas, in this case), and one level up (to HTML, generally, in this case). Because the authors are particularly concerned with HTTP performance, details of the interactions between HTTP and adjacent levels can be important.
The book is divided into five main sections: 1) an overview of HTTP, URLs, and connection management; 2) HTTP Architecture, including Web servers, proxies, caches, gateways, tunnels, robots; 3) Identification, Authorization, and Security; 4) Entities, Encodings, and Internationalization; 5) Content Publishing and Distribution, including hosting, publishing, load balancing, logging. So, even if you classify yourself as a "D," or even if you are hacking on an extensible open-source router software platform (in that case, you are an "F"), you will find yourself pulling this book from the shelf from time to time to check on something in one of these areas. The modular organization of the book is good.
The full Table of Contents is available on line.
Depth One (unfortunate?) thing about the Web is that its "architecture" (if you can even call it that) evolved and grew piece by piece. The design goals people had in mind back in 1993, or even in 1999, have been blown away by what has happened on the ground. Inter-company politics have also been a big factor -- never helpful for promoting standardization, or sound design. (Perhaps another problem has been the lack of an O'Reilly book on HTTP to tie everything together!) Hence, not only do you have a confusing mass of obsolete and/or overlapping specifications documents, you also have major differences between how different browsers, servers, and proxies adhere to these specifications in practice. This is one place the book shines: sprinkled throughout the pages are little tidbits about compatibility or performance pitfalls, gleaned from much practical experience. (The authors were some of the architects of Inktomi's Traffic Server "enterprise class" Web cache. Think "proxy caching for all of AOL's Web traffic.") As one example: "Technically, any Connection header fields (including Connection: Keep-Alive) received from an HTTP/1.0 device should be ignored, because they may have been forwarded mistakenly by an older proxy server. In practice, some clients and servers bend this rule, although they run the risk of hanging on older proxies." I can just imagine the series of bug reports leading to the inclusion of that piece of advice in the book. There are many other such warnings and bits of advice, generally aimed at HTTP application developers, often with an eye to performance tuning.
Here again, appropriate depth of discussion for a variety of readers is handled by clear organization of the book. The basic background material is laid out, and as the authors dive deeper into detail they may make a suggestion like, "If you are [not] writing high-performance HTTP software... feel free to skip ahead." Then, at the end of every chapter, there is a section labelled, "For More Information," which is a collection of relevant references and links, for those who want to dig into the source documents themselves.
Cautions This book review is addressed to the Slashdot crowd, a very technically savvy audience, so it's appropriate to mention what this book is not. It's not a detailed technical reference on all the topics mentioned in the table of contents (above); it would be tough to fit all that material into the book's 650-plus pages. However, the book is a good overview of HTTP and many related topics. The book does dip down into the grungy detail in many areas, but this won't be your only reference if you are a Web application developer.
Conclusion Overall, this is one of the more accessible O'Reilly books I own. In addition, while experts will certainly seek out greater depth in their particular area of expertise, few people are expert in the whole range of topics related to HTTP that this book covers. In addition, the book provides many tips drawn from practical experience, and references to more detailed material. HTTP, if not the heart and soul of the Web (perhaps that is Web content itself), could perhaps be called the Web's circulatory system. If you have a professional interest in Web content distribution, or Web application development, I believe this book deserves a spot on your shelf.
You can purchase HTTP: The Definitive Guidefrom bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I think I'll download it to my PDA and go deprecate for a while...
Stop by my site where I write about ERP systems & more
True or false questions should not be followed by a list of four choices, none of which are "true" or "false."
I choose:
E) CowboyNeal gives good header
Damn grognards.
A) What does "deprecated" mean?
deprecated: adj. In a state of having soiled oneself. Johnny was not efficient enough and failed to reach the restroom, and was thus deprecated.
"I only speak the truth"
Karma: null(Mostly affected by an unassigned variable)
QUESTION: Did you know that the Keep-Alive header was valid in HTTP 1.0, but has been deprecated in HTTP 1.1?
Uhh, my answer is "No"
--
If you deprecate in here, you'll clean it up.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
that would be, I don't use HTTP... I use Gopher you insensitive clod!
===================
QUESTION: Did you know that the Keep-Alive header was valid in HTTP 1.0, but has been deprecated in HTTP 1.1?
A) What does "deprecated" mean?<br>
B) What is the "Keep-Alive header?"
C) That's too bad - I kind of thought Keep-Alive was handy!
D) Get with the program... HTTP 1.1 came out in 1999. The Internet boom is over already! Persistent connections are the default in HTTP 1.1 anyway.
============
Well, I'm no HTTP expert but I do know this -- that <br> tag doesn't belong there.
What I'm listening to now on Pandora...
...I have someone I can fire if they don't know the answer to this question.
everyone with any real cred still uses HTTP 1.0.
/some/file.xml
Huh? To get real cred, you do:
: telnet foo.bar.com 80
GET
And you hit Return twice, of course, but you knew that.
HTTP 0.9 is the Real Thing.
Hey, anyone remember HTTP 0.5?
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
HTTP must be at 6.0! Why else would I need Internet Explorer 6?
402 -- Payment Required
406 -- Not Acceptable
300 -- Multiple Choices
Where do you think you can find HTTP on the W3C site?
And yet, as has been pointed out, you can indeed find it on the w3 site.
The RFCs on HTTP are useful if you are writing a server or client, however they are less useful as a guide to how what is out there works.
But, as anyone who's tried CSS or just about anything else knows, this is absolutely true. Differences between vendor implementations are one reason why many geeks are bald, sickly, and pale.
Tweet, tweet.
Me know HTTP real good!
Aww, I miss blink. I used to have a version of my webpage wherein every other word blinked. It was actually quite pretty, in a geeky epileptic sort of way.
Whoever stated that signature sizes should be limited to one hundred and twenty characters can just go ahead and kiss my
One of the big problems with the IETF is that the RFCs look like shit, they are designed to be printed in a fixed width font because thats the way they did things in Babbage's day. So not surprisingly engineers tend to go for documentation that is easier on the eye, even if it turns out to be wrong.
:)
I don't know about that. I'm an engineer, and I'd rather have something printed in fixed-width font, on green-and-white fanfold paper. Less BS, more facts.
"Soon to be a Microsoft standard."
--- Ban humanity.
(reload a couple of times)
Yes, I did have something to do with it. Sorry.
Avantslash - View Slashdot cleanly on your mobile phone.
The blink tag works great for papers on quantum physics.
(Credit to UserFriendly goes here)
What's this Submit thingy do?
I'm an IIS coder, you insensitive clod!
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
A) What does "deprecated" mean?
"No matter how much we pretend otherwise, this will stay around forever."
Save your money, here's my guides to HTTP.
Client sends:
GET (uri)
Server sends:
(the web page)
This concludes the guide.