Forgot your password?
typodupeerror
Programming Books Media Software The Internet Book Reviews IT Technology

HTTP Developer's Handbook 206

Posted by timothy
from the spitting-back-responses dept.
honestpuck writes "To say that understanding HTTP is crucial for web development might seem like saying water is wet, yet many people don't take the time to fully understand the protocol. This book could be a good help. HTTP Developer's Handbook from SAMS gives you a great deal of information about the protocol in a clearly understood fashion." Read on for the rest of honestpuck's review.
HTTP Developer's Handbook
author Chris Shiflett
pages 280
publisher Developer's Library/SAMS
rating 6 - Serious flaws
reviewer Tony Williams
ISBN 0672324547
summary Mixed volume with fair look at HTTP protocol

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.

This discussion has been archived. No new comments can be posted.

HTTP Developer's Handbook

Comments Filter:
  • by phamlen (304054) <phamlen@m a i l .com> on Wednesday September 17, 2003 @01:34PM (#6987130) Homepage
    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?

  • w3c (Score:5, Insightful)

    by stonebeat.org (562495) on Wednesday September 17, 2003 @01:35PM (#6987139) Homepage
    why would i wanna "buy" a book, that has info that is already available on http://www.w3c.org [w3c.org]?
    You can also join the W3c mailing lists to get in-depth info on any of the technology stacks.
    • Re:w3c (Score:4, Insightful)

      by bmj (230572) on Wednesday September 17, 2003 @02:02PM (#6987349) Homepage

      why would i wanna "buy" a book, that has info that is already available on http://www.w3c.org?

      Because (and get ready for this, it's a bit shocking) some people actually prefer reading a book to staring a computer screen (and not everyone has access to a printer to make hardcopies of the w3c specs).

      GASP!

      • Re:w3c (Score:3, Funny)

        by 4of12 (97621)

        some people actually prefer reading a book to staring a computer screen

        I couldn't agree with you more completely.

        I've found the phosphors on my vt100 were getting painful to look at, so I just printed out all 4000 of the published RFCs on my dot matrix printer.

        No need to spend money on those needless books when I can learn everything from the source.

        I do have a question, though.

        I've read up on this HTTP and have been using telnet on port 80 to answer all those GET commands that have been coming into

  • by Ratface (21117) on Wednesday September 17, 2003 @01:35PM (#6987144) Homepage Journal
    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!!".

    • As I see it, it is a handy reference. Not telling anyone anything new or exciting, or even giving information that can't be printed out from the Web. But it's a handy condensing of things that an HTTP-interfacing developer might need to know.
      I think you're right that few people will need to know all of it.
    • 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.
  • by nepheles (642829) on Wednesday September 17, 2003 @01:35PM (#6987151) Homepage
    I'm not convinced that web-developers need a knowledge of HTTP. Even sessions can be handled very transparently with newer web-dev languages/dialects like PHP and JSP. Sure, it is a benefit to have an understanding, but the average developer is better off putting his work into understanding Dreamweaver or Photoshop.

    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.

    • by Hayzeus (596826) on Wednesday September 17, 2003 @01:38PM (#6987166) Homepage
      Ha! The average web developer is would be even better off with a basic grasp of graphic design principles.
      • by Anonymous Coward on Wednesday September 17, 2003 @01:42PM (#6987204)
        There it is, one of the huge misconceptions. Web developers write code (most of them anyway, some of us do both)... it's the web designers who would be better off with a basic grasp of graphic design. That's like telling an electrical engineer that he should take some sculpting classes.
      • The average web developer would be better off with a basic grasp of bandwidth issues. Maybe then we wouldn't have to wait 30 seconds or more to access such a large majority of pages.

        I'd especially like to whack developers who put large Java or Flash intro pages.. especially those with no way to skip them. Okay like it's cool that you can write your company name in a fancy font and make it zoom around but really who gives a damn? If you want to make movies then make movies. If you want to make a website the
    • Web-development does not require a knowledge of HTTP

      Ever sent a file to a browser that is dynamically generated, and isn't an inline image or a html/txt page?

      Or maybe you wanted to handle file uploads, while the languages have built in functions for handling them, those functions are usually pretty bad at handling anything special, or providing feedback to the user on the progress of the upload.

      It helps to know HTTP. It's not one of those things you need to know, but without knowing it, you won't be ab
    • by JimDabell (42870) on Wednesday September 17, 2003 @01:47PM (#6987238) Homepage

      I'm not convinced that web-developers need a knowledge of HTTP.

      For hobby sites, no. For proper sites, definitely. Far too many people build a site without any understanding of how the browser talks to the server. Common mistakes include:

      • Thinking web statistics are reliable.
      • Wasting bandwidth by massive amounts
      • Slowing down sites by not being able to take advantage of HTTP pipelining, more efficient caching, etc.
      • Thinking the Referer and User-Agent headers are reliable.
      • Trusting request variables.
      • Serving different content to different clients without providing a Vary header (in other words, letting caches screw things up).

      It's not a trivial topic that can be glossed over. You could literally waste gigabytes of bandwidth a month on a high profile site (or single slashdotting) if you don't pay attention to the interaction between server and client. While it's certainly possible to build a site without knowing the first thing about HTTP, it shouldn't be encouraged.

      • by ceije (662080) on Wednesday September 17, 2003 @02:11PM (#6987419) Journal
        I'm not convinced that web-developers need a knowledge of HTTP.
        For hobby sites, no. For proper sites, definitely. Far too many people build a site without any understanding of how the browser talks to the server.
        I think that for a programmer or admin working on a web site of any size, it's good to have a basic understanding of HTTP. It's doubly important for those working on a large site. I work at a pretty heavily-trafficked web site and when we were looking for performance improvements, the first thing we did was look through Apache release notes. We found that an HTTP issue in the version of Apache we were running at the time caused graphics that were distributed across mutliple servers to be treated by web clients as different files, hence not cached.

        By removing the inode portion of the entity tag (ETag) response in HTTP headers we were able to get a 40% reduction in files served because of client-side caching, which reduced the last byte page load times for most users, and allowed us to repurpose several web boxes to serve dynamic pages.

        It was a really trivial fix that made a big difference to user experience.
      • For hobby sites, no. For proper sites, definitely. Far too many people build a site without any understanding of how the browser talks to the server.

        But these kind of things are mostly dwarfed by making a site overly graphic-heavy. That's the number one problem. Make a site that's lean, and you're 90% of the way there.
    • I respectfully disagree. Afterall, the argument could be made that an understanding of HTML really isn't that important; rather the web developer should spend their time getting to know Dreamweaver or Frontpage. There are several problems with ignoring the basics. For one thing, when you find yourself in a situation where either the tool is unavailable or the tool cannot accomplish the desired effect, you have no idea how to proceed since there is no understanding of the framework (ie. A Frontpage design

    • I couldn't disagree more.
      How about a fundamental understanding of cookies?
      From the text:


      Although cookies are most often described in conversation as if they are entities (for example, "a Web server sends you a cookie"), they are much easier to understand at a functional level if you consider them an extension of the HTTP protocol, which is actually more correct."

      (Shiflett goes on to describe the Set-Cookie and Cookie headers.)

      Relying on a given scripting language's manipulation of HTTP requests/respo

    • If you saw some of the sniffs from stuff built by devs who don't know HTTP and then hear them wonder why their stuff is slow you would change your mind. If devs had a basic understanding of HTTP then maybe just maybe they would build stuff that did not use insane amounts or bandwidth.
      • While I'm all for education, and knowing what your tools do, it is arguable that we don't really need a million monkeys writing web pages on the bare metal. Let them have Dreamweaver. As long as the few who can really make HTML/HTTP dance and sing can find the information they need, we'll still have useful innovations and a cadre of experts who can handle the tough questions.

        See Asimov's story "Olympiad" for an interesting take on this notion. It's all economics, man.

        (Yes, I am trying to make some of t
        • The dreamweaver monkeys are web designers, not web developers. Sure, designers don't need to know much about HTTP, but developers who start messing about with response headers should. Sadly, far too many just copy and paste without trying to understand.
    • I'm quite proud to say that I don't know how to use dreamweaver, and I'm a web developer. I learned with notepad and pico, and I still code by hand (although now with Homesite).

      I've been on interviews where I had to convince the interviewer that I was a competent developer, despite not knowing FP or dreamweaver.

      Off the topic, can anyone recommend a good HTML editor for linux? Something like Homesite in terms of features (coloring, validation) would be nice.
    • I disagree. There are times when a web developer DOES need to get down and dirty with HTTP. I can think of two intances (off the top of my head) that I ran across:
      1. IE's disasterous handling of mime types and Content-Disposition
      2. Bug in IE client that was dropping packets. I had to view HTTP packets in ethereal to figure that one out
      I found O'Reilly's HTTP: The Definitive Guide, 2002 invaluable for solving the first problem.
    • Web-development does not require a knowledge of HTTP, and this is the way it should be.

      Just as modern application development, apparently, requires no knowledge of programming or computer science.

      People who have a deep mental model of the layers below the layer they work in tend to be much better developers. Why is it that these prople are always the problem solvers that everyone else goes to in any shop?
    • Please don't confuse "designer" with "developer".

      I'm engrossed in HTTP at the moment writing a proxy server with HTTP::Proxy in Perl that appends authentication headers to requests from specific IPs that have specific cookies set so that I can log into all sites I visit that use basic authentication without having to remember my damn logins and passwords all the time.

      Next step will be to combine with WWW::Mechanize module (probably) to automate logins to other sites that use standard forms for login.

      Unde

    • I'm inclined to mostly disagree. While its nice that many developers can code for the web w/o understanding the intracacies of HTTP and TCP/IP, a grounding in such knowledge can only help, and a lack of this knowledge can lead to one looking like a bozo and/or code-monkey.

      I am reminded of a situation from a few years ago when I was interviewing for a corporation that wanted to put together an ASP/COM/MTS-based intranet site. The interviewer was/is the project manager for this project, and he very clearly

  • by 192939495969798999 (58312) <info@noSPaM.devinmoore.com> on Wednesday September 17, 2003 @01:38PM (#6987172) Homepage Journal
    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?
    • Advanced topic books really are hard to find in a sea of "me too" books aimed at novices. One book I remember well was titled Garbage Collection. (Don't have it handy, and don't remember author.) It is a big, expensive hard cover. Very through treatment of the subject. Another excellent book I remember was Peter Norvig's book on AI and Lisp in about '91 or thereabouts (sorry, don't remember exact title).

      I wonder how many people will see this book on HTTP and get excited thinking it is another book t
    • I hardly buy any computer books anymore. Most of the topics I need to know about aren't covered well in books yet when I need to know them. It's often difficult or impossible to find in-depth books much less up-to-date in-depth books about cutting-edge topics.

      A couple times I've thought of writing an in depth book about a topic I'd finally fully explored.. to save others the trouble.. but then when I think about it who is likely to publich such a book? How many people would buy it? I could just post the te
  • by goldspider (445116) <ardrake79 @ g m a i l . com> on Wednesday September 17, 2003 @01:38PM (#6987173) Homepage
    Not to troll here, but why does every book review here conclude with the reviewer's assertion that the book they reviewed is a good reference?

    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"??

    • What does it take for a reviewer to come out and declare "THIS BOOK ISN'T WORTH THE PAPER IT IS PRINTED ON"??

      Ummm ... no check from the publisher?

    • What does it take for a reviewer to come out and declare "THIS BOOK ISN'T WORTH THE PAPER IT IS PRINTED ON"??

      I thought that was why Slashdot was only offered online?

      -Bill
  • 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.
  • by Anonymous Coward
    Fellow Slashdotters, prepare to be dazzled! Well, as Timothy already mentioned, the name of the book that I read was HTTP Developer's Handbook. It's about these ... protocols. HTTPD ... with requests ... and ... responses ... and XML-RPC ... Did I mention this book was written by a guy named Chris Shiflett? And published by the good people at Developer's Library/SAMS. So, in conclusion, on the Slashdot scale of one to ten, ten being the highest, one being the lowest, and five being average, I give this
  • Good Review (Score:4, Insightful)

    by Khomar (529552) on Wednesday September 17, 2003 @01:40PM (#6987185) Journal

    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.

    • Thank you, Khomar.

      One comment like this makes up for many posts implying I am paid to do this (I'm not) or receive a benefit from the B&N link at the bottom of the review (I don't - OSDN gets that money) or even employed by one of the publishers (I'm actually unemployed at the moment).

      I hope you continue to read and appreciate my reviews. I enjoy writing them.

      You'll be glad to know that I'm writing two more reviews at the moment and have another couple of books on the stack.

      Tony Williams

  • *shudder* (Score:2, Funny)

    by inkedmn (462994)
    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... :)
  • it was worth the $ (Score:5, Informative)

    by websensei (84861) on Wednesday September 17, 2003 @01:40PM (#6987191) Journal
    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....

  • by Anonymous Coward on Wednesday September 17, 2003 @01:42PM (#6987205)
    To say that understanding HTTP is crucial for web development might seem like saying water is wet


    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"



    • by idontgno (624372) on Wednesday September 17, 2003 @02:02PM (#6987353) Journal
      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"

      Sage words in this dangerous day. Imaging Drinking 101:

      See these two hydrogens and one oxygen? Drink that.
      See these two hydrogens and two oxygens? DON'T DRINK THAT!
      Now, throw in some carbon:
      Two carbons, six hydrogens, one oxygen: Drink that (carefully, preferably well hopped and poured slow).
      One carbon, four hydrogens, one oxygen: Don't drink that (thin paint with it though).

    • Not quite. Saying "To be able to drink water you must first understand the various ways in which hydrogen and oxygen can combine" is like saying "To browse the internet you need a complete understanding of HTTP".

      A closer analogy would be "To be able to mix Kool-ade, you must first understand the various ways in which hydrogen and oxygen can combine"
    • Web DEVELOPMENT, not Web Design...
      Get the two straight.
  • by joshv (13017) on Wednesday September 17, 2003 @01:43PM (#6987207)
    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
    • 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.
      And how would you approach that?
      • Coding at random until all user agents worked with it.
      • First, reading something about the protocols.
      • And how would you approach that?
        Coding at random until all user agents worked with it.
        First, reading something about the protocols.


        Read the book AND write a web server. The two in combination will result in a much deeper understanding of the protocol.

        Myself I just rooted around in specs and RFCs from the early 90s - took a little longer, but it got the job done.

        -josh
  • by igorko (701584) on Wednesday September 17, 2003 @02:00PM (#6987333)
    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.

    1. most people use it to "design pages", not represent data. H1, H2 .. tags are miserably neglected (in favour of, say, FONT). Flash, on the other hand, is used where it shouldn't be.

    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
  • by Anonymous Coward
    HTTP Developer's Handbook

    Huh? I thought the HTTP protocol was already developed.

  • Not just using POST for changing state server side and GET for other stuff is a mistake that is often made...

    The REST stuff [conveyor.com] is good on this...

    Also the W3C document on URIs, Addressability, and the use of HTTP GET and POST [w3.org], a document being debated on the W3C Technical Architecture Group (TAG) list [w3.org] is debating at the moment [ thread 1 [w3.org] | thread 2 [w3.org] ] also well worth reading...

    I wonder if REST is covered in this book?

  • Honest Criticism (Score:5, Informative)

    by shiflett (151538) on Wednesday September 17, 2003 @02:13PM (#6987442) Homepage

    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 [shiflett.org].

    • by ukpyr (53793)
      It seems to me, most of the confusion comes from people who use the term "web developer" to mean someone who uses HTML to make static web pages.

      Maybe it's regional or something but to me and people I know, "web developers" are programmers who use server-side technologies like mod_[perl/php/whatever], ASP, JSP etc etc etc who would actually care about what is happening in the HTTP request process because they (can) directly influence it.

      I call people who use things like Dreamweaver, Frontpage, or notepad t
  • "...had Shiflett given up on the newcomer and given the developer greater depth...."

    Talk to the editors. They seem to think everything should be For Dummies nowadays. "Lauguage X for People who Already Know How to Program" books are rare gems indeed.

    OTOH I think that a lot of those fat books on the store shelves spend *too much* space on sample code. Many of them seen to be primarily code libraries on an eccentric distribution medium, and I often find myself wondering why they didn't just publish the c
    • Addison-Wesley produce a number of excellent beyond-beginner books such as Large Scale C++ programming, Effective C (and one for C++), Effective STL, etc. which have all been both good reads for information AND reference. (I mean, if a book doesn't make a good reference, is it really a good book?) Also, look at O'Reilly's Perl Cookbook series.

      Granted, I would REALLY love to see more advanced books out there, but you tend to get to a point where you're looking for a book on an entire subject in a particul
  • by EkiM in De (574327) on Wednesday September 17, 2003 @03:04PM (#6987960)
    I found the HTTP Pocket Reference [amazon.com] 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.
  • by kfg (145172) on Wednesday September 17, 2003 @03:06PM (#6987980)
    . . .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
    • A real artist always knows her materials, right down to the last atom.

      Indeed. It's sometimes surprising how often lower-level details that you "shouldn't have to be aware of" stand up and bite you if you don't understand them.

      Right now, I'm looking at a bizarre bug that has been plagueing me for a year or so, in which little chunks 3 or 4 extra bytes appear scattered through out downloaded web pages. I finally tracked it down to the HTTP level. How many web developers could tell you what "chunked" dat
  • by $exyNerdie (683214) on Wednesday September 17, 2003 @03:33PM (#6988278) Homepage Journal
    This 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 [faqs.org] and save some money.

    You can also read: HTTP/1.1 Specifications [w3.org]

    Easy to understand and best of all FREE!!

  • Hmmm, a section defining HTTP: 80 pages

    Pure coincidence? I think not.
    .

To err is human -- to blame it on a computer is even more so.

Working...