Slashdot Mirror
HTTP Developer's Handbook
One of the strangest feelings I've ever had reading a book is that I have a better opinion of it than does the author. Shiflett spends most of the introduction convincing the reader that this is a useful book and it seems that the start of most chapters is another few sentences telling me why the chapter is incredibly useful for me to read. I felt like yelling "I'm convinced, I'm convinced."
The book is broken up into 6 parts: 'Introducing HTTP,' 'HTTP Definition,' 'Maintaining State,' 'Performance,' 'Security,' and 'Evolution of HTTP.'
The first section and a large part of the introduction are the sort of information that is covered elsewhere in just as good a detail: it basically covers the obvious. The second section covers the HTTP protocol itself, with a good discussion of requests and responses, including all the nitty gritty details of the headers in some detail. This is the really useful heart of the book and it covers 80 of the 280 pages. The third, fourth and fifth sections give a too-concise look at their subject matter, I felt the book could have given much more detail here. The last section is a waste of space; in this volume I don't really need to have a small amount of information about SOAP and XML-RPC.
This book is well-written; I believe its two fatal flaws are that Shiflett seems unsure of his own book and that the book itself tries to offer everything for a developer while explaining it all for the newcomer. I think that had Shiflett given up on the newcomer and given the developer greater depth (with a lot more examples) he would have delivered a much better book. For a developer, the volume is much too light on example code, the book is not really 'practical,' more 'informative.'
This might be a good volume for a library, either a corporate or school library. It provides the salient information in one spot in a concise and readable manner. I think that an individual might find it a less than totally useful book for the money -- you're likely to have already have a volume or two that covers most of the information, and with most languages in web development having libraries that take care of most of the low-level stuff for you, it becomes less and less necessary to really understand the bottom level. Personally, I'll keep it for the 80 page section on the HTTP definition so I have it all in one spot.
You can purchase HTTP Developer's Handbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Understand the protocol? Heck, I've been doing web development for 10 years and I can't even remember what the acronym means....
What does that second T stand for?
why would i wanna "buy" a book, that has info that is already available on http://www.w3c.org?
You can also join the W3c mailing lists to get in-depth info on any of the technology stacks.
Consensus is good, but informed dictatorship is better
If you think about it there are very few people who actually *need* to get down and dirty with the HTTP protocol itself. OK - most of those who do are probably reading this and I'll be shouted down, but in reality there aren't that many people who'll be jumping up and down saying "Wow! All I ever wanted to know about HTTP!!".
A little planning goes a long way...
Web-development does not require a knowledge of HTTP, and this is the way it should be. You shouldn't need to understand ASCII, etc., to use a word-processor.
((lambda x ((x))) (lambda x ((x))))
It seems that more and more books that are coming out are geared for the novice... or perhaps, we're all just getting that much better? It's important to ask yourself how good you really are. I have found that there are practically no good resources for programming information above a certain level, i'd say Junior Programmer, other than the Knuth books or perhaps a few others. Anyone else know of any advanced topic books that are really good?
stuff |
After reading the mostly-negative review, how am I supposed to believe that it is in fact "a good volume"? The reviewer even says that most people would find it to be a waste of money!
What does it take for a reviewer to come out and declare "THIS BOOK ISN'T WORTH THE PAPER IT IS PRINTED ON"??
"Ask not what your country can do for you." --John F. Kennedy
Every developer should be forced to write a simple HTTP server just so that they understand the basic mechanisms of the protocol. But the full details go way, way beyond what I'd expect someone on my team to know (or spend time learning) unless they were writing a server, a HTTP client, or low-level HTTP interface functions.
An efficient developer is one who is protected from the details of the technical world, and who can spend his energy and time on the functional aspects of his problem.
That's my conclusion after 20 years of (mainly successful) software projects.
Ceci n'est pas une signature
Shiflett spends most of the introduction convincing the reader that this is a useful book and it seems that the start of most chapters is another few sentences telling me why the chapter is incredibly useful for me to read. I felt like yelling "I'm convinced, I'm convinced."
This may have been the first sign of trouble. I always hate it when salespeople or authors waste my time telling me what I already have grasped and understood. After a while, I start to question whether I really should be interested it in anymore if they are so concerned that I won't be.
I think I will try to check this out at the library for a quick refresher course, but it doesn't sound like one to add to my own library. It is good to see an honest review that doesn't immediately gush with adoration and praise while glossing over the flaws. While another poster questioned the frequency of reviews from honestpuck, the quality of this review leads me to ask him to keep up the good work.
I believe in de-evolution. God made the world perfect, man fell, and its been going downhill ever since!
shouldn't there be a time frame given for how long it will take you to learn? how the hell am i supposed to give my client an accurate lead time if i can't tell him (10 Minutes | 24 Hours | 21 Days)!?!?
:)
what a crock...
well, it's nothing one behind the ear wouldn't cure
this was a great book as an overview, and as a quick reference for details on http headers.
it's eminently readable, and while I agree w the reviewer that it's light on examples, the writing is clear enough that in most cases, examples would be redundant.
very little filler and very readable, easy to read in 1 or 2 sittings and come away with a much better handle on the underpinnings and details of the request/response model. the web is not as well understood by page authors / web developers as it should be, and this is an excellent book to help remedy the situation.
I give it a solid 7/10 and am glad I read it.
it's within easy reach on my shelf....
La via sola al paradiso incommincia nel inferno
no, it's like saying "To be able to drink water you must first understand the various ways in which hydrogen and oxygen can combine"
Just write your own web server, in whatever language. You will become intimately familiar with the HTTP protocol. That is if you implement form processing, cookies, and multi-part encodings and such.
-josh
Same link minus the ccats-20 crap. Why bother to even post anonymously?/
http://www.amazon.com/exec/obidos/ASIN/0672324547
Morphing Software
Far too many web developers forget what the FIRST T stands for....
www.eFax.com are spammers
Sure, some developers won't grasp HTTP is a stateless protocol. Others remain ignorant of the fact it's trivial to spoof and continue to rely on the the refferer as means of session tracking. But that's not where the big problems are. They lie in misuse of HTML.
.. tags are miserably neglected (in favour of, say, FONT). Flash, on the other hand, is used where it shouldn't be.
1. most people use it to "design pages", not represent data. H1, H2
2. small fonts (guess what: verdana is NOT cool), sans-serif for main text, low-contrast hard-to-read colors, and so on.
3. propriatery HTML (say IE 6.0+ only), fixed-resolution design
and many other bugs of the sort. Reading W3C's HTML 4.01 & CSS2 specifications and some usability guides (www.useit.com) should be more insightful than following up on HTTP headers. What works for me is knowing it's stateless, what this means, cookies and url rewriting, and SSL/TSL. The only time I used cleancut HTTP was when testing certain servers via telnet 80.
Verisign and networksolutions are an additional problem, but that's another story altogether.
For a webdesigner, the protocol details are of little use. There are more important things to study.
-i
Huh? I thought the HTTP protocol was already developed.
I appreciate the honest feedback, and I'd like to address a few concerns/criticisms/whatever that I have seen mentioned.
Convincing the reader of the importance of HTTP - The first few pages do focus a lot on explaining why HTTP is important to a Web developer. Just look at all of the comments that mention how knowing HTTP is useless, and you can hopefully see why I think this is important. I see questions on various mailing lists all the time that reflect a general lack of knowledge in this area; developers don't really understand cookies, when SSL is needed (or what it does), how to secure their sessions (or applications in general), how to keep up with data from one page to the next, and all sorts of things.
The book caters to beginners - I want the book to cater to both the beginner and the experienced developer. HTTP isn't rocket science, and it can provide a great foundation for Web developers to build from. For those who are already experienced, the book can provide a good reference to the protocol (if you're experienced, you should also know that RFC 2616 isn't a substitute for this) and can help people gain a deeper understanding of things they already know a little about. I don't think a book has to confuse the reader to be considered advanced, and I wasn't writing to impress anyone. My approach was to try and help as many people as I could.
Learn Dreamweaver, not HTTP - Well, people with this opinion might be a lost cause, but what happens when your next place of employment thinks FrontPage is the only way to write Web applications? In general, I think it is better to teach people fundamental things and let them apply those things in any way that they want.
I also have a companion Web site for the book at http://shiflett.org/books/http-developers-handbook .
You just discovered the difference between making pages like the pros, and being a pro.
I found the HTTP Pocket Reference to be an incredibly useful book in those times when you just have to know what that status code or header means. There is enough explanation in this book that it can be used as a guide to HTTP.
Patriotism is the opium of the masses
. . .more 'informative.'
.
And so we descend, bit by pleasant little bit, into hell, where "information" isn't "practical," where knowledge of reality isn't "necessary" and where, it turns out, the enviroment is a cube farm populated by clueless code monkeys happy to be there.
Sorry for wading into this thread after yelling "Flame On!", but reading most of the responses is just plain depressing.
The older I get the more I understand why Fabian Pascal tends to come across as a bit bitchy. He's earned the right.
Helloooooo, are there any geeks left in the house?
My mom has a degree in fine arts. Not a very geeky field, right? She took chemistry for years so she could understand her materials, particularly glazes. Is this necessary to throw a pot? No. Is it necessary to be a good ceramicist? Yes.
A real artist always knows her materials, right down to the last atom.
Otherwise you're just a semiskilled mechanic working on an assembly line.
Of course, it that was your goal when you set out . .
KFG
KFG
You can use this one to support the author (me):
http://www.amazon.com/exec/obidos/ASIN/0672324547Or, here is the plain link (it's not cheaper; you just give Amazon more money):
http://www.amazon.com/exec/obidos/ASIN/0672324547This book could be a good help. HTTP Developer's Handbook from SAMS gives you a great deal of information about the protocol
You can buy the book
OR
You can read the documentation of RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 and save some money.
You can also read: HTTP/1.1 Specifications
Easy to understand and best of all FREE!!
The people who really need to know already have what they need in the RFCs. But there are a surprising number of web developers who don't know the first thing about the protocol. Like you, they think they don't need to know the details, and end up making big mistakes as a result. A book like this deserves a place on every web developer's bookshelf.
Worse, most web developers arn't geeky enough to know what an RFC is or how to look one up. A lot of them don't know anything about http at all other than it's the four letters at the start of most URLs. That's fine. The great thing about the web is that it's easy enough that you can be a developer without knowing how things work. You'll be a better developer though if you do know how it works. Knowing http is especially useful if you do any actual programming. If you want to know how to do some of the fancier tricks of web development you'll need to learn at least the basics of http.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.