- 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
> 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 http://www.ics.uci.edu/~fielding/
Received on Thursday, 15 August 1996 18:32:06 UTC