W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

Re: HTTP/1.1 : Chunking

From: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
Date: Fri, 30 Jan 98 07:45:04 EST
Message-Id: <199801301300.AA16338@reston.vmd.sterling.com>
To: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5323
Adrien de Croy <adrien@qbik.com> writes:

>With the reasons given, I have removed chunking from my list of redundant
>(?) complexities in HTTP/1.1 (which I am still building, although I will
>raise a couple here).

I suggest you go back to the HTTP 1.1 Proposed Standard (RFC 2068) and
read section 3.1 "HTTP Version".  It describes the rules under which
this group makes changes to the protocol, and what limits we place upon
ourselves.  Pay particular attention to the first paragraph:

   "HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
   of the protocol. The protocol versioning policy is intended to allow
   the sender to indicate the format of a message and its capacity for
   understanding further HTTP communication, rather than the features
   obtained via that communication. No change is made to the version
   number for the addition of message components which do not affect
   communication behavior or which only add to extensible field values.
   The <minor> number is incremented when the changes made to the
   protocol add features which do not change the general message parsing
   algorithm, but which may add to the message semantics and imply
   additional capabilities of the sender. The <major> number is
   incremented when the format of a message within the protocol is

As you can see, one of the rules in developing HTTP 1.1 was that HTTP 1.0
clients and servers have to be able to process HTTP 1.1 requests and
responses as if they were HTTP 1.0.  Any incompatible change to headers
or to basic rules that were in place in HTTP 1.0 is disallowed a priori.
We've deferred a number of good ideas for exactly that reason already.

While some of your suggestions might bear considering for a future
replacement protocol (HTTP 2.0 or later?), they all fly in the face of
the rules for extending HTTP 1.x.

Ross Patterson
Sterling Software, Inc.
VM Software Division
Received on Friday, 30 January 1998 04:59:05 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC