- From: <touch@isi.edu>
- Date: Tue, 18 Feb 97 10:37:48 PST
- To: luigi@labinfo.iet.unipi.it, touch@isi.edu
- Cc: bertold@tohotom.vein.hu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, www-talk@www10.www3.org
> > > From bertold@tohotom.vein.hu Sat Feb 15 09:02:38 1997 > > > > > > This is interesting to me. Look at this (excerpt from HTTP/1.1 spec): > > > "HTTP communication usually takes place over TCP/IP connections. The ... > > Joe said: > > By the way, section 3.2.2 gives a the only clear definition of > > http_URL, which indicates that > don't have the document handy, but if, as you say, the spec says > two different things in two different places, it is just arbitrary > to pick one definition as the correct one and the other as wrong. I did not. The question is twofold. HTTP can be implemented over whatever, as you observe. The spec is very clear on the meaning of http://, however. It is TCP specific. > Ok, current implementations use TCP over IP as the only transport, > but I fail to see where the protocol is so tightly related to TCP/IP > that it would be hard or impossible to make it work with another > reliable protocol. It is tightly tied to a connection-oriented reliable transport protocol. Sure, it CAN work with others; the question is whether it's http: or not. I claim not. > host and port are just identifiers, to the point that, even in > current implementations, they are quite often remapped to other > hosts and/or port numbers in a totally transparent way. Huh? Since when does port 80 mean anything but? Proxies can be used to fake you out, but that doesn't change what the client thinks its doing. > As a result of this discussion (for which I thank all who replied > to my original posting giving useful suggestions), I am completely > convinced that there should _not_ be a specification of the network > transport protocol in the URL, since the same exact data might (and > certainly will in the future) be available over different transports, > and it would be a serious issue to embed the transport in the URL. And how do you propose figuring this out? Checking all possible protocols? In what order? These are a few things a protocol might specify. HTTP 1.1 doesn't. > To me, the use of TCP is as good as any other protocol, what I > would be worried about is that the assumption of TCP/IP then creates > TCP-specific details which would be hard to reproduce in different > protocols (e.g. the use of IPv4 addresses as identifiers, etc.). You're already stuck with most of that, as per 3.2.2, unless it's revised. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/
Received on Tuesday, 18 February 1997 10:59:27 UTC