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.
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.
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"
--
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.
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!
here
It's nice to see a review like this. Many slashdot reviews are short and detail-less, but this one is a good overview, which I like.
As much as I want to know about the underpinnings of HTTP, I find this one of those "books I'd like to HAVE read." If I buy it, which I may, I'm pretty sure it will be one of those books I just don't get around to reading because I personally don't have a huge need for it. I'd love to know the information, but I don't know I have the time to pull off actually reading it. Is it just me, or does everyone have a few of those books - the ones you wish you had actually read, but instead just look nice as part of your technical book collection?
I guess there's at least one positive about the Matrix - I can make a quick phone call and have my operator just load "The Complete HTTP" for me.
I figure XHTML 2 is going to require a big re-design of everything anyway, why not design an HTTP 2.0 to go with it?
The problem with definitives guides is that, they get outdated very quickly :)
so i wouldn't spend any money on them. instead i would just browse the W3C website or other reference web sites.
Consensus is good, but informed dictatorship is better
> 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
===================
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...
You're trolling, but are you sure? A lot of Code Red box "owners" didn't know that they were running web servers. (And "click on everything" install-types aren't limited to Windows.)
One line blog. I hear that they're called Twitters now.
...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.
HTML != HTTP"
Nice try killjoy. Just makes it funnier!
I don't have a printer to print them on, and I don't have a laptop/pda. I want to read these on the bus or on the shitter or on the couch.
HTTP must be at 6.0! Why else would I need Internet Explorer 6?
402 -- Payment Required
406 -- Not Acceptable
300 -- Multiple Choices
Me know HTTP real good!
What does wargaming have to do with this?
can i get a "who cares?"
---
I browse at +5 Flamebait- moderation for all or moderation for none.
http://www.cgisecurity.com/rfc
http://www.cgisecurity.com/libbr
until divs will auto resize we'll be stuck with pages like this one (light orange on white for them menus ffs!) that only go 20% to the width of my browser window.
& his menus don't resize to fit the text if you turn up the size
still, never mind, im sure he makes $ from his book, but not from me
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Standards should be lean and so easy to understand and so trivial to implement that one undergrad student can implement it to full compliance in one afternoon.
HTTP 1.1 has over 100 pages, most of them absolutely useless for implementors. Unnecessary verbiage, unnecessary optional parts, unnecessary warts, unnecessary "I'm working on a thesis about foo, let's put it in this standard and see what happens" crap.
Examples: chunked encoding -- absolutely superfluous! Amazingly useless. Or what about the range support? HTTP allows to request a byte range from a file. Normally you would use that to fetch the second half of an aborted download, or maybe for PDF reading you would fetch bytes 10 to 100 or so. HTTP 1.1 allows to specify several ranges in the same request, and the server is expected to construct some MIME abomination as answer, if it supports this at all. If it doesn't, it is allowed to coalesce the ranges and just send the whole range. This makes this feature horrendously useless for clients (why bother with it if you a) have to implement some sort of complicated parser to understand the result and b) won't even save bandwidth because the server isn't going to implement it in the first place and c) it is not even cheaper than just using keepalive connections and asking for the parts one by one.
In short: HTTP needs to die quickly and be replaced by something sane.
Did I mention the monstrosity that is content negotiation? It is impossible to write a proxy that can cache content in the face of content negotiation. Luckly, nobody uses it on their servers, because it is a pig to implement and configure on the server. Clients tend to support it, but who cares.
putting : and | in title tags, or even in the html filename,
like --> www.numbnutz.org/I_am|an:ass hat.htm
Not to mention other illegal characters.
Spaces in the filename suck too..
It plays havoc when you save pages to disk.
The internet is FULL of geniuses
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.
...to show the history of when HTTP became MSIEHTTP.
The coolest voice ever.
"Soon to be a Microsoft standard."
--- Ban humanity.
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
I've kept "Web Design in a Nutshell" within arm's reach for about three years now, and while the only reason I need it nowadays is when the bud kicks in, it was an enourmous help when I was trying to learn HTML and related technologies. YES, I know the submitter said HTTP, I'm talking about a different O'Reilly book.
Even if it doesn't seem like the smartest thing to do (I just posted yesterday about how I'd never buy a programming book), O'Reilly makes some damn good books.
"Hey, anyone remember HTTP 0.5?" ... grabs ear, gnashes teeth, "AAAhhhhhhh" flees from room...
The Kruger Dunning explains most post on
(reload a couple of times)
Yes, I did have something to do with it. Sorry.
Avantslash - View Slashdot cleanly on your mobile phone.
It's because you are one, you worthless fuck.
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.
A bit OT, but related to HTTP. I noticed that I can sorta get around the URL filtering firewall where I work if all I wanted is the HTML. When you type a request in telnet, the characters (at least the first one) are sent one at a time. This means that each character of the request is sent as a separate packet. The firewall here doesn't (or isn't configured to) assemble the packets and determine the full URL -- none of the packets will appear to contain a blocked URL, so the request goes through. Of course, I could also TS or SSH to another machine outside the firewall, but that's like cheating.
"No one likes working in a hamster wheel, and your shop smells of cedar shavings from here." - TaleSpinner
The solution is to fix the server, not break the client. If everyone wrote strictly standards complient, a broken implementation would easily be recognized as such, no one would use it, and it would be quickly fixed or die.
By being permissive about nonstandards compliance (or is that standards noncompliance?) you are encouraging sloppy coding. To use a pop-psychology metaphor on your example, Mozilla is the "enabling" girlfriend who is too insecure to leave her abusive/addicted/noncomplient boyfriend.
Give me Classic Slashdot or give me death!
Most webservers, at least Apache and IIS answer queries terminated with two line feeds (\n\n). However the RFC says it should be carrige return, line feed twice (\r\n\r\n). I noticed slashdot don't answer if you don't send it the proper RFC way. Some other sites I tested that run slashcode answered with \n\n. Anyone know how they did this?
A lot of Code Red box "owners" didn't know that they were running web servers. (And "click on everything" install-types aren't limited to Windows.)
But code red is.
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.
+1 troll
Standards should be lean and so easy to understand and so trivial to implement that one undergrad student can implement it to full compliance in one afternoon.
I suppose that appeals to undergrads, and those who like extremely granular standards that only address small parts of a solution. Beyond that, it's an absurd overstatement. Standards should be lean in the sense that they should be focused, but to be trivial enough for full implementation by an undergrad in one afternoon ducks below the bar of general usefulness. It's somewhat analogous to what I've heard more than one teacher respond when asked by a student "how long" a paper should be: It should be like a skirt -- long enough to cover the important parts, short enough to keep it interesting. You're right that it should be lean (short enough to keep it interesting) but your criterion for that might not cover the important parts.
No Laughing Allowed!
A) What does "deprecated" mean?
"No matter how much we pretend otherwise, this will stay around forever."
Strictly speaking, RFCs are not standards -- only government-sanctioned bodies can issue standards. Of course, that's a distinction only of interest to compulsive nit-pickers (aka Tech Writers).
In practical terms, I think a good RFC plays the role both of a standards document (MUST) and a best practices document (SHOULD). Given the ad hoc nature of the Internet, it makes a lot of sense to combine the two. It's the sort of informal process and documentation that has allowed the net to grow so quickly.
And (the bring us back to the real topic) that's a good reason to not waste money on a book if there's a good RFC at hand.
Not true. Should is OK in specs.
From Fowler's "The King's English" on the subject of "Shall and Will"
"Roughly speaking, should follows the same rules as shall, and would as will;
Shall had the meaning of command or obligation, and will of wish. "
In much the same way, isn't it written "shalt not steal" instead of "mustn't steal".
[credit where credit's due... a few days ago Andrew Sullivan pointed this out on the postgresql list where talking about the SQL spec]
Someone must be trying to get a spam crawler to pick up these addresses.
not fun at all
robi
To quote the W3C:
Now that both HTTP extensions and HTTP/1.1 are stable specifications, W3C has closed the HTTP Activity. The Activity has achieved its goals of creating a successful standard that addresses the weaknesses of earlier HTTP versions.
If you were using Mozilla you could have picked from one of three stylesheets that he provides. Try orange - it looks really nice.
The US Army: promoting democracy through unquestioned obedience
Save your money, here's my guides to HTTP.
Client sends:
GET (uri)
Server sends:
(the web page)
This concludes the guide.
The spec and books are both good sources of information on HTTP, but I find it difficult to actually apply the knowledge.
I recently interviewed for a position requiring intimate HTTP knowledge. Rather than try and understand every bit of the spec, I just captured all of my clear text HTTP traffic for a night of surfing, I then looked at the actual HTTP exchanges between my web browser and various servers and looked things up in the spec and other sources that I didn't understand.
I also learned some things that weren't in the spec, which were helpful in the interview like how session keys are structured on various servers, etc.
(Score:-1, Wrong)
Oh, baybee, I am SO with you on this one!
The lack of contrast literally makes my eyes water!
Wut wuz he theeenking?
Brak: What's THAT?
Thundercleese: A light switch.. of TOTAL DEVASTATION!
Mine are definately content negotation, specifically language negotation, since I develop multilingual websites (yeah, English is not my first language).
I find that extremely useful, yet, nobody cares about it... It is really annoying when you get to a website and you have to choose the language, "Hey, I told you that in my accept-language header, just listen!"
Things are moving sooooo slowly...
Employee of Inrupt, Project Release Manager and Community Manager for Solid
I may even buy this book, since it appears to offer some insight into how HTTP is applied in the real world, rather than how it ought to be applied.
oh brave new world, that has such people in it!
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.
[Here's the text of the article in case it gets /.ed.]
:-)
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, t
the RFCs are a definition of a standard, any application that deviates from their specification is inherently not worth paying any mind
People here who made the web happen? They are the reason standards started and evolved in a way they did - WWW was "a collabaration tool for high-energy physics" after all. BTW - we should invite them to do an interview here on Slashdot.
<^>_<(ô ô)>_<^>
Informative presentation..
<^>_<(ô ô)>_<^>
I hate it when people post spoilers before I've read the book!
Not just for showing me the code ... but also for showing me that pathetic isn't always something to be deprecated.
Infuriate left and right
You're not allowed to write informative posts! If you're going to spoil our flamebaiting and trolling, you can at least accept responsibility for your actions!
Mod this idiot down, he could not do half the stuff he does today on the internet if it was not for chunked encoding...
Got Code?
Really? Most of the CSS-layout pages I design have three, maybe four DIVs. You should look into that, I bet you can get rid of quite a few of them.
Multi-column layouts are annoying as hell. Yeah, they're annoying in tables too, but damn. That's why there's entire web pages devoted to getting away from tables with weird, complicated CSS
First of all, a few years ago I found tables to be "weird and complicated". Then I spent some time learning how to use them and now they make sense. Ditto for CSS; it took a little while and sme practice before I really got to know how it worked, but now those multi-column layouts seem almost intuitive. Also, I believe CSS3 is introducing new features specifically to make column layouts easier. Remember when complaining that CSS isn't a dead standard.
Example 1: I want to make a form. Forms look nice if the labels are all lined up and all the form elements are lined up. Let's assume I want a page that can have varying size text (which is what people say should be allowed with css).. Ah fuck, can't use divs here. Oh well. I tried. From what I've found, there's no way to link the size of one div to the size of the others in a way that makes logical sense to the document format and flow.
I'd like you to elaborate on this one.
Example 3: Picture page. Captions on the bottom of thumbnails.
The float method does work pretty well. Check out this tutorial. And what's this about an extra line screwing it up? Are you specifying fixed heights for your DIVs or something funky?
Personally I'm a fan of CSS because it makes my layouts much more flexible (I can switch around stylesheets and such with amazing ease) and my markup much more readable. You can have my CSS when you pry it from my cold, dead hands.
But what about that Not Acceptable? You would think that Apache would spit that out for goatse.cx.
certainly a great idea. However, from my experiance (and theres been very little) A lot of diffrent clients or supporting platforms, dont seem to support it as well as it could.
:}
We were useing it with PHP on a recent project, that was returning XML to javascript from an HTML page.
When keep alive was turned on, Network performance off course would be a little better off, however, for some reason we had various unexplained crashes.
We didnt put it down to keepAlive at first, but eventualy we found out that when it was turned off, we had no problems. This was annoying because speed was a major factor of our project.
Its a shame its been depreciated, but from my experiance, a lot of vendors didnt seem to support it properly.
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
Your name is Philip Hallam-Baker. You were a self-important tosser when I met you, and by the sound of things, little has changed.
Actually, in many ways, the Gopher protocol is a far better way to deliver HTML than HTTP.
Unfortunately, the idea never caught on, mostly becasue most browsers don't leverage or support the features of Gopher that would be useful (like, for instance, being able to tell how big something is *before* you download it, something that HTTP can't do. Try the "=" command on a Gopher link to see it work, and think how useful that could be on the web.)
The Gopher protocol (as distict from Gopher clients) was probably a far better option than HTTP. Unfortunately, about hte time we had the chance to make the change, the newly formed web was inundated by PC users that had discovered Cello or Mosaic, and we all thought it would be too hard to make the change. In retrospect, it woudl have been far easier then, of course. Oh, well, win some, lose some...
"The future's good and the present is nothing to sneeze at." - Roblimo's last
hello
what gnu and what kernel dose the squerrel use?
and is it only in the one flavor(squerrel?)?
Interesting how my previous comment above has wasted two separate MOD points from someone be being moded down.
I used my mod points for Awsome. What do you use them for?
First, this is off topic, as is commonly associated with HTML, not HTTP, which this guide is about.
Second, has never been in HTML. Netscape supported it, but it's never made it to the HTML standard, just like tag from IE. (See the Bare Bones Guide to HTML (not related to Bare Bones Software)
Build it, and they will come^Hplain.
but I find it difficult to actually apply the knowledge
/shameless-plug >
It depends what you do. When I first started web scripting on a new platform (ASP) I had problems with cookies, trying to see why cookies were being sent sometimes and not others. Watching an HTTP stream makes it much easier to measure results properly, plus you can see things like chunk-encoding, which slows transfers over low-bandwidth lines, but increases responsiveness by sending results before the full results are generated (without dropping back to HTTP 1.0). With ASP and IIS you don't have direct control over when this happens, but after fiddling for a while you can see how to provoke it, and how to prevent it when required.
Nowadays you may not need to know this stuff, but when you do need it, you need to be able to see the subtleties of the stream (as you point out).
< shameless-plug >
To watch the HTTP stream I wrote hacky little perl script HttpSniffer that is available on my web site - handy for when you haven't got the ability to capture all the raw TCP/IP (eg Win2K to Win2K inside a corporate environment). It's really an HTTP tunnel, but you can use it to watch headers, negotiations, and will produce timing info too.
Doing this I also found a few spots where various web servers don't quite meet the specs (or the specs are sort of vague) so you have to guess precisely what's happening...
<
--
T
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best
< shameless-plug >
/shameless-plug >
To watch the HTTP stream I wrote hacky little perl script HttpSniffer that is freely available on my web site - handy for when you haven't got the ability to capture all the raw TCP/IP (eg Win2K browser to Win2K server inside a corporate environment, or you have to debug interactions with a new web client on someone else's machine).
It's an HTTP tunnel (cf xmon for tracing X), but you can use it to watch headers, see authentication and other negotiations, and if you want it will produce timing info too.
<
--
T
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best