Slashdot Mirror


HTTP 1.1 approved by W3C and IETF

fabbe writes "The HTTP 1.1 protocol has been approved by the W3C and IETF. CNET article is here. " Both bodies apparently showed ruthless efficiency getting these standards out there... speeds that make even glaciers jealous.

14 of 78 comments (clear)

  1. Doing something PROPERLY takes time. by Anonymous Coward · · Score: 4

    I was watching a show called "Flightpath" on Discovery channel last night and they were showing all sorts of nifty things about the new YF-22 fighter aircraft. This is the new hybrid stealth fighter that is going to replace the F-15 for general figter missions.

    This plane has been under development more or less for the past 19 or 20 years. Although there are 9 or so flight ready versions of this plane which exist TODAY, there will not be any in actual military service for about 5 more years. Some people have described these planes as the most complex machines ever built. They HAVE to work perfectly because if they don't, the pilots will probably be killed and their strategic value will be lessened.

    When much of the software being used today is labelled "mission critical" don't you think it should be well thought out and done PROPERLY as well? Perhaps not 25 years, but don't you find it amazing how stupid is it to spend so much money on software that only partially works?

    The notion of "internet time" is complete and utter BS, invented solely to give software companies excuses for shoddy software and to make "lazy programmers" seem more productive.

  2. HTTP 1.1? by pb · · Score: 2

    What's wrong with HTTP 0.9? All I really *need* is "GET /" anyhow... :)

    --
    pb Reply or e-mail; don't vaguely moderate.
  3. This is why open standards suck by YuppieScum · · Score: 2


    Commitment to open standards is all very well, but the standards bodies themselves need to commit to ratifying those standards while there is still a business case to use them.

    Products and markets won't wait if a 'proprietry' solution gets the job done now - budgets need to be spent.

    --
    This sig left unintentionally blank.
  4. Re:Ah... by sjames · · Score: 2

    If that's the case, then it may provide a noticeable improvements for people with higher-speed connections.

    It can help slow connections even more by saving the latency of the three way handshake and by not having to do slow start (with more latency) for each file transfer.

  5. Are most web servers already using HTTP 1.1? by timur · · Score: 2

    I'm confused - I thought HTTP 1.1 was old news. Don't a bunch of servers and web browsers already support this? I know IE 4.0 does - under the advanced options, you can select whether it uses HTTP 1.1.
    Timur Tabi
    Remove "nospam_" from email address

    1. Re:Are most web servers already using HTTP 1.1? by artdodge · · Score: 2
      The problem is there are 8 version of HTTP/1.1, including RFC2068, six IETF drafts, and RFC2616. Lots of implementations are against RFC2068, and there are a LOT of problems with that version that are addressed the later ones (expect and TE request header, even MORE excrutiating cache-control detail, etc.)

      Also, since HTTP/1.1 isn't being exercised very well by most current clients, the 1.1 support code in most servers is only lightly exercised and often is buggy/incorrect/broken.

    2. Re:Are most web servers already using HTTP 1.1? by windshield · · Score: 2

      Most servers do, but most clients don't. IE40 says that it does in the advance settings, but it just seems to be another microsoft interface element that wasn't wired up to any actual code. I've tested IE40 with 1.1 on, and my server log the requests as 1.0.

      IE5 does it properly.

  6. Ah... by Aglassis · · Score: 2

    One thing I do like about it is the ability to use multiple names per IP address. But this sort of kills the elegance of design of domains going from TLD, First level domain, and so on. But if I'm interpretting it correctly, it should kill alot of the refer jumps. I wonder what the speed difference is with the fact of concatenating packets into streams rather than placing 1 packet per 1 stream. I'd guess that for small servers it would be trivial but for large ones the change would be enormous.

    --
    Suddenly, the hairy finger of a familiar monkey tapped me on the shoulder. It was time.--G. T.
  7. HTTP/1.1 performance and other issues... by jg · · Score: 5

    It wasn't quite as glacial as one might think.
    The draft standard was approved in March; the
    RFC issued recently when the RFC editor caught
    up on backlog. The internet drafts have not had
    a significant change for nearly a year. Most
    vendors have been working to the ID's for a long
    time.

    HTTP/1.1 has already been pretty widely deployed:
    this was the approval of the draft standard,
    rather than the proposed standard.

    As to performance stuff, see:
    http://www.w3.org/Protocols/HTTP/Performance/

    As to recovering IP addresses, most clients
    have been sending the host name as part of the
    request using the HOST header for a long while.
    This means you can distinguish different web sites
    without depending on the IP address to distinguish
    them.
    - Jim Gettys
    HTTP/1.1 editor.



  8. Re:old news by Razorblade · · Score: 2

    The previous draft versions of HTTP 1.1 are flawed and are not fully standardized. Implementations of draft HTTP 1.1 are inconsistant and partial. The standardization of HTTP 1.1 is the actual full, standard, final version of HTTP 1.1. It addresses many issues ignored by RFC 2068 (draft HTTP 1.1).

    --
    DES Khaddafi KGB genetic jihad Uzi Rule Psix Qaddafi cryptographic Peking Mossad Legion of Doom Albanian Serbian Saddam
  9. Snail's Pace by MidKnight · · Score: 2
    The people behind IETF & W3C amaze me. Seriously, can you imagine how hard it is to get a world-wide collection of people, some of which don't even speak the same language, to actually agree on technical issues? It has to be damn difficult. Thus the slow painful process of getting the standards passed through.


    I wonder if those organizations are built using the same ideas of the original routing protocols :) Route around trouble, with no built-in solution to thrashing.


    Seriously, can such an organization keep up with the explosive growth of the Internet? Will IPv6 get out before I need my toaster to have an IP address? And does anyone know where IPv5 went?


    So many questions.... --Mid

  10. Virutal hosts and authentication by Chronoforge · · Score: 3

    I'll try to answer a couple of the big questions I've seen here from RFC 2616 (HTTP/1.1) and the Apache docs.

    Virtual hosts:
    Currently, a request looks something like
    GET / HTTP/1.0

    But under HTTP/1.1, it looks more like
    GET / HTTP/1.1
    HOST www.example.com

    This way, the webserver knows what domain to serve the request from.

    Now, this assumes that you referred to the webserver by name. If you refer to it by IP, the request looks like:
    GET / HTTP/1.1
    HOST 192.168.12.27

    Or, if you're using an HTTP/1.0 browser, the request would be
    GET / HTTP/1.0

    In either case, Apache (I don't know about other servers cause I don't use them) will serve the request from the first VHost that matches that IP -- see http://www.apache.org/docs/vhosts/name-based.html

    Thus, If you're running a children's educational site and a pr0n site on the same IP, not only are you an idiot, you should have the server direct older browsers and non-DNS users to a page that says 'Oops' (and possibly a list of the sites you serve).

    Authentication:
    Under HTTP/1.0, the only supported authentication mode was basic. The username and password were base64 encoded for transmission, but not encrypted.

    With HTTP/1.1 we get MD5 encoding.

    This whole message will make a lot more sense if you read the Apache docs, RFC 1945 (HTTP/1.0, it's shorter than 2616[HTTP/1.1], and good for the basics), and RFC 2617 (Basic and Digest HTTP Authentication).

    --
    Dave Richardson

  11. In praise of glaciers by coyote-san · · Score: 3

    The long ratification times can be annoying, but it's better than the alternatives. We're all frustrated at the Netscape and MSIE "extensions" to HTML. Imagine now that the HTTP was also changing as frequently.

    How much time do shops waste getting "compliant" MSIE browsers and "compliant" Netscape browsers to render the same source document into reasonably close fascimiles? How many shops give up and have separate MSIE and Netscape trees?

    Now multiply that by the HTTP 1.0 server, the 1.1 server, the 1.1b server, the 1.2 server, the 1.3 server, and the 2.0 server. You would either see development slow to a crawl, or a lot of shops simply announcing that they would support a single server/client pair. The one that is bundled with every PC sale due to it's unquestionable (*not* 'unquestioned!') technical excellence. *cough*

    Gee, maybe Microsoft is right and having a strong Imperial hand *does* help competition. King Bill could have simply announced that everyone shall use HTTP 1.1 (after paying another $200 for the privilege of serving his liege, of course) years ago, and by now we would be running HTTP 1.4 complete with 'Microsoft' 'innovations' such as push technology, dedicated "channels", and Lord Bill knows what else.

    --
    For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
  12. For more information... by rwg · · Score: 2

    Here are a few more links for more information about HTTP and some neat things that are being done with it...

    • Get the latest dirt from the World Wide Web Consortium.
    • RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 ( text, PostScript, PDF)
    • Berkeley's TranSend service is a cluster of workstations working together to act as a massive HTTP proxy. This proxy "transforms" Web pages based on clients settings. Was the basis of the ( now-commercial) Top Gun Wingman Web browser for the PalmPilot.
    • The Anonymizer acts as a proxy that strips out all the unwanted/unneeded header lines that your Web browser sends.

    I had started hacking together an HTTP/1.1-compliant proxy in perl that did on-the-fly compression if the client supported it, but I never got around to completing it. Initial results were impressive, especially when it was paired with a caching proxy like Squid or a CacheFlow box. Of course, with DSL and cable modems getting more widespread use, people like myself that are still pinned to a 33.6k connection are being left behind.

    Caching/compressing/proxying is still in widespread usage outside North America (most notably Australia and European countries). Their problem was (is!) outrageous access prices and relatively slow overseas connections, so they've been using caching for a long time to help solve it. The US and Canada have solved their "problem" of Web pages not instantaneously loading by throwing more bandwidth at it...