New issues: What should we say about HTTP .9? 1.0? Do we leave this one to IESG/IAB to handle? (We're thinking of removing references to .9 from document, leaving it to the 1.0 RFC). (JG to see if we can get IESG/IAB to issue a separate position RFC, rather than cluttering up our spec, on encouraging adoption of 1.1.) Editorial questions: What to do about w3.org in URL examples? Is there some other, better site to use for them? Is it worth changing them? (no, not worth changing them.) What is the state of Wrapped? (JG to check with Rohit to determine disposition, revisit next week) I moved patch, copy, move, delete, link, unlink to appendix, but left put. Is this correct? (No, delete should have been left in main document) What, if anything, gets done with Logic Bags? (cutting room floor, should not appear in document is Referer spelled correctly? (Yes, sic). What to do about Multipart in document (Roy to review to see if anything is an issue.) I replaced 3.7 with section from 1.0 document. (right). Is removal of MIME-Version correct? (should it go to appendix?) (moved to appendix.) Section 1.3 problem about connections. (JG to fix wording) What to do about content-MD5 name vs. canonicalization? Should we rename to different header and be done with it? (PL to try once more to fix wording; if any more problems turn up, we'll move to appendix) Go over issues list to see which we believe we might/should still close out before freeze for 1.1, and which might/should be deferred. (Several were deferred, and lots more marked resolved. See updated list) Schedule (my sense is that we're running between 3 days and a week late, folks). (Yes, we are. Panic not yet set in, but will set in soon). Status reports: Persistent connections (Still no draft. Sigh. If none appears, Roy will take over). Caching (Draft mostly done, and mostly out for review) Content negotiation (Accept almost consensus, but Vary and Alternates are still in draft state). Digest authentication (Draft done, about to be issued) Range retrieval (dunno) State management (Dave is checking one more time with Lou Montoulli over last nits, but about to have new draft done). New issues mail: From: Paul Leach To: 'Jim Gettys' Subject: FW: 505 HTTP Version Not Supported Date: Wed, 3 Apr 1996 12:39:36 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Length: 748 Maybe we should talk about this tomorrow... >---------- >From: jern@sdrmis.jhuapl.edu[SMTP:jern@sdrmis.jhuapl.edu] >Subject: Re: 505 HTTP Version Not Supported > [ elisions...] > >Then perhaps it's time to be explicit about retiring 0.9. I find >it useful in my intranet environment but I see no reason this >should burden the Internet. We could say that "If you use 0.9 in >an Intranet environment, then this environment should be shielded >from the Internet." I can't believe I'm the only one still using >0.9, but if so, I'll happily withdraw any request to preserve 0.9 >and stuff them in a tiny server behind my firewall and drop any >claim about HTTP. The same thing might apply to anyone who wants To: jern@spaceaix.jhuapl.edu (Bob Jernigan) Cc: hallam@w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com Subject: Re: 505 HTTP Version Not Supported In-Reply-To: Your message of "Wed, 03 Apr 96 13:42:45 EST." <9604031842.AA16903@sdrmis.jhuapl.edu> Date: Wed, 03 Apr 96 15:43:08 -0500 From: hallam@w3.org X-Mts: smtp Content-Length: 2260 Resent-Message-Id: <"6JfZX3.0.3E.hFkOn"@cuckoo> Resent-From: http-wg@cuckoo.hpl.hp.com X-Mailing-List: archive/latest/178 X-Loop: http-wg@cuckoo.hpl.hp.com Precedence: list Resent-Sender: http-wg-request@cuckoo.hpl.hp.com I really don't understand the arguments concerning 0.9. It really does have very little use. Consider the simplest possible HTTP 1.1 request GET /foo/bar.html HTTP/1.1 Host: www.foobar.com:80 I don't think that this is very much more complex! Then we have the simplest reply parser:- 1) Check for HTTP/x.x 2) If not present we have hit one of the very few remaining 0.9 servers. act accordingly 3) Otherwise gobble up the status code and headers. If the first digit of the status code was a 2 we have some content. Otherwise we don't. If a language makes it difficult to implement such code easily then the solution is to try a new language. Perl and TK implementations are not madatory for IETF acceptance. There are decent libraries arround in any case. I would like to see a statement to the effect that 0.9 will be phased out in future versions of the protocol. For the entire period of use of 0.9 it has been subject to future revision. Its existence has never been guarnteed. When 0.9 was superceeded there were fewer than 100 Web servers in operation. I would be suprized if any of those servers was still in operation (bar possibly the REXX based servers on CERNVM and DESY-NEWLIB which are in any case condemned machines). If one considers some of the problems occurring becuase of unread input etc. I very much doubt that many platforms could support a 0.9 server which is unaware of 1.0 with any great reliability. Remember that in the days of 0.9 the Web was in any case pretty ropey which was part of the need for a change. If a 1.0 client connects to a 0.9 server the headers part of the 1.0 request will be unread by the server. This will in turn mean that the server will close the socket with unread data which in many stacks causes a reset command to be sent which is likely to result in unread data. This type of effect was a common problem in the 0.9 to 1.0 upgrade period. The simplicity of implementing 0.9 should be set against the complexity of supporting 0.9 in a 1.1 framework. I don't think we should continue to discuss the issue at this time. The best we can do in 1.1 is to warn people that 0.9 may not be required in future and that clients must not assume that it will be avaliable. Phill