W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: HTTP 1.1 Server Available for Testing

From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Thu, 15 Aug 1996 18:28:51 -0700
To: "David W. Morris" <dwm@shell.portal.com>
Cc: "John C. Mallery" <jcma@ai.mit.edu>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9608151828.aa17443@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1369
> On Thu, 15 Aug 1996, Roy T. Fielding wrote:
>> Great -- but what I was saying is that you can't be sure you are conforming
>> until the document stops changing, which means when the IESG recommends
>> it for RFC status.  So, you need to wait for that before you can ship
>> software that responds with "HTTP/1.1 200 OK".
> C'mon Roy, they announced an experimental implemntation and solicited 
> testing against it with experimental HTTP/1.1 clients. Your response
> is quite harsh when you should be lauding their attempts to verify the
> specification by attempting to implement it.

I said "ship" -- as in letting it go outside your area of control where
you can personally ensure that changes to the protocol can be fixed
in the server code and thus not result in long-term faulty applications
in the hands of users that might not want to upgrade them.

If John hadn't said he was planning to ship it soon, I would not have
bothered.  In any case, these messages are directed at the entire WG
and not just his server (in fact, his server is the least of my worries,
since he has better control over his user base than other servers do).

>> I don't anticipate any more changes to the protocol, but stranger things
>> have happened.  I'd like to minimize the number of noncompliant servers
>> advertizing HTTP/1.1, and one way to do that is to encourage people to
>> implement the features within HTTP/1.0 first and only switch the version
>> when it can be tested against a completed RFC.
> Impossible Roy ... many aspects of the new protocol depend on the version
> for a experimental client to recognize the server as 1.1 and vice versa.

There is nothing in HTTP/1.1 that an HTTP/1.0 server cannot send to
an experimental HTTP/1.1 client -- the only necessity is that the client 
not have the normal attribute of disregarding HTTP/1.1 features received
from an HTTP/1.0 server.  Nor is there any requirement anywhere that
forbids an HTTP/1.0 server from properly interpreting HTTP/1.1 requests.

Being able to use HTTP/1.1 features within HTTP/1.0 is one of the design
requirements that Henrik and I laid down at the beginning.  It would be
nice if people would take advantage of it.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
Received on Thursday, 15 August 1996 18:32:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC