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.
Or, you could just check out the W3C and read up on it without the need of someone making edits to the explanations of the actual specs.
Mozilla Sends:Which isn't necessarily a bad thing, but they have to be backwards compatible in case they hit a poorly implemented HTTP 1.1 server. Gets annoying to code hybrid httpd systems.
HTTP isn't that complicated of a specification though, the RFC is easy enough to understand.
Dacels Jewelers can't be trusted.
Honestly, save yourself ~ $50 for an O'Reilly book and go directly to the source of the information:
HTTP 1.0
HTTP 1.1
It's remarkably easy to read for a technical document.
> 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. >
I couldn't agree with this more from a web development area as well, so many designers are still using hack and slash methods from the early 90's it's sad[although not always their fault!]. It correlates to the same principles used to build the architecture itself.
side note: if you're interested in learning more about forward compatible web design you should check out Jeffrey Zeldman's new book 'Designing With Web Standards' you can find him at www.zeldman.com - I just finished this book and it was well worth the $24.50 - all you nested table designers should pick this one up or those looking to bridge the gap from using tabled design. =)
Fear Breeds Knowledge
The first and fully accepted meaning of deprecate is "to express disapproval of." But the word has steadily encroached on the meaning of depreciate. It is now used, almost to the exclusion of depreciate, in the sense "to belittle or mildly disparage,".
a te d
http://dictionary.reference.com/search?q=deprec
*psst*
HTML != HTTP
Gibble: Descriptive of an emotional state in which one's mind is scrabbling for some purchase on reality
Uhm... that has absolutely nothing to do with HTTP, does it?
An AC Writes: ...
> I figure XHTML 2 is going to require a big re-design of everything anyway,
XHTML 2 has been working in many browsers since August, 2002, even though it's still a draft. Part of the point of point of XHTML 2 is to cleanly re-seat HTML on top of the stack of stuff that browsers are supposed to implement already (CSS, XML, linking, etc.).
deprecated
Deprecated
A deprecated element or attribute is one that has been outdated by newer
constructs. Deprecated elements are defined in the reference manual in
appropriate locations, but are clearly marked as deprecated. Deprecated
elements may become obsolete in future versions of HTML.
User agents should continue to support deprecated
elements for reasons of backward compatibility.
Definitions of elements and attributes clearly indicate which are
deprecated.
This specification includes examples that illustrate how to avoid using
deprecated elements. In most cases these depend on user agent support for style
sheets. In general, authors should use style sheets to achieve stylistic and
formatting effects rather than HTML presentational attributes. HTML
presentational attributes have been deprecated when style sheet alternatives
exist.
Error 300 isn't as unusual as you might think.
s 1
Apache's mod_speling module will correct small typeos in URLs that are requested, and if it finds more than one possible match it returns an error 300 with the possible choices.
For example:
http://www.madriver.k12.oh.us/network/netware/wef
- Bunny
Um...chunked encoding is not useless.
If you've got dynamic output, and don't want to buffer then entire content so you can generate a Content-Length header, then chunked encoding is for you. There's no reason for a server to be buffering up a potentially huge reply if the client can accept it piece-meal instead.
I thought it was common knowledge by now that you always check (at least) buy.com for the cheapest price before pointing people to bn.com or amazon.com.
bn.com price: $44.95
buy.com price: 28.31
I have no affiliation with buy.com, except I've saved a lot of money with them.
For the full-featured HTTP server that I designed and implemented at my last job...I found just one book to be all the help a person needs:
... good grief!!
"HTTP Pocket Reference", O'Reilly, maybe 4 bucks at Bookpool.
75 pages, of which about 65 aren't necessary.
656 pages on HTTP??? 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.
Nope - it allows for pipelining dynamic content without buffering it all beforehand.
Nope. It's called the Vary header, look it up.
Nope, it's just a case of dropping a couple of files into the same directory with similar names, and switching on MultiViews in Apache. On the fly switching between GIF and PNG, for example:
logo.png 15034 byteslogo.gif 18455 bytes
<img src="logo" alt="[MyCo]"
Troll city. I'll bite.
Chunked encoding is usefull to me everyday. I use a protocol one level up from HTTP1.1 (AS2) where messages and their digests are transferred in the same request - in chunks.
As for supporting ranges, this is why agents are encouraged to delegate difficult MIME handling to helper apps like a Flash plugin. Plenty of servers implement this, it's actually not even that hard. There is a separate issue related to what a range response actually represents (in the theoretical sense), but I won't touch that for now. Read www-tag @W3C for more info.
Content negotiation works nicely. We serve French pages to agents that prefer French. We also serve unstyled xml to agents which we're sure are not browsers. It's not hard to do, we look at a header and then decide which representation to serve. Caches use the Vary header to choose which responses to serve from cache. It's not rocket science.
My favorite part: "HTTP needs to die quickly and be replaced by something sane"
Yeah, it'll never catch on.
I used this book in addition to the RFC when writing my webserver software.
It's a good addition to the RFC's but not a substitute. The introductory stuff is a bit too basic but the rest of the chapters clarify several things about the RFC's. 2616 can be a bit ambiguous at times.
All in all, it was worth the money if you are planning to do any serious work with HTTP.
I don't know what is more pathetic: that you would make requests just to see X-Bender headers, or that I would know where to look in the slashcode CVS to see the list (scroll down to the end of that page.)