- From: Dan Connolly <connolly@w3.org>
- Date: Fri, 14 Feb 1997 16:06:23 -0600
- To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, www-talk@www10.www3.org
Luigi Rizzo wrote: > I have a questions that is somewhat related to HTTP. What is the > best, and cleanest, way to specify the reliable transport protocol > (intended as Network Transport Protocol, e.g. TCP, something-above-UDP, > etc.) used to transfer HTTP data ? > And, what is the correct way to make the mechanism explicit ? Perhaps by > instructing the browser/server to use TCP only, and then add, locally to > the client/server, an independent gateway which does the translation ? > Hmmm... good question. I'm not certain which way to go, but a couple clarifying questions come to mind: Given a resource available via this hybrid transport, let's suppose we use the string S for its URL: Suppose a client that doesn't support this new transport finds S in a document. What do you want it to do? (1) go ahead and fetch it via http over TCP, since it's likely to be available that way as well (2) error out; if you don't grok the new transport, you can't access the resource. If (1), then S should be spelled http://dns.host.name/... In this case, I'm not sure what will provide the clue to the new clients that they should use the new transport. Does the new transport gateway to TCP/IP? i.e. are regular old resources like http://www.yahoo.com/ available via this transport? If so, then it's just a proxy/gateway, and the client doesn't need any explicit clues in the URL, any more than http clients using firewall proxies do. If clients do need explicit clues, I suppose the stuff after the two slashes should be used to indicate it. Somebody suggested something for DECNET transport once... I don't remember it exactly, but it was something like: http://a.host.name:hybrid/... another obvious option is: httph://a.host.name:/... Dan
Received on Friday, 14 February 1997 14:14:47 UTC