- From: Henrik Frystyk Nielsen <frystyk@w3.org>
- Date: Thu, 15 Aug 1996 23:14:37 -0400
- To: Bill Janssen <janssen@parc.xerox.com>
- cc: www-lib@w3.org, msa@hemuli.tte.vtt.fi (Markku Savela), Howard@telemedicine.clh.ed.ac.uk, msa@msa.tte.vtt.fi
Bill Janssen writes: > Excerpts from mail: 15-Aug-96 HTTP/1.1 vs HTTP/1.0 servers Markku > Savela@msa.tte.vt (2069) > > > The new wwwlib library sends by default the request as HTTP/1.1 > > This seems wrong, doesn't it? ``Be conservative in what you send, and > liberal in what you accept.'' But, of course, how else to gain > experience with 1.1? It is true that the default version is HTTP/1.1 - exactly as you say in order to try it out. However, libwww keeps a cache of the information it knows about remote servers and if it knows that it is a HTTP/1.0 server it sends a HTTP/1.0 request and likewise for a HTTP/0.9 server (if they still exists). I should say that the HTTP/1.0-HTTP/1.1 distinction is new and has not been released yet. The difference in a libwww HTTP/1.0 and an HTTP/1.1 request is only the version number as HTTP/1.0 doesn't disallow any of the headers sent by HTTP/1.1. Roughly speaking, the only method that is significantly different is PUT and libwww handles this by pausing between sending the header and the body. This is required anyways as almost all HTTP/1.0 servers reacts to large amounts of incoming data by doing a TCP reset (indirectly by doing a two sided close). This results in the HTTP response being lost as the TCP stack must not deliver reset information to the application. Therefore to make PUT work reasonably reliably for HTTP/1.0 the behavior is almost identical to HTTP/1.1 except for the 100 Continue code in the middle. In theory, the rest should work fine but as Markku quickly found this is not quite the case in practice. If there are too many problems like this then it may have a significant influence on the speed by which HTTP/1.1 will get employed and we might as well find out sooner than later... Henrik
Received on Thursday, 15 August 1996 23:14:41 UTC