Full URLs in GET
John C. Mallery <JCMa@reagan.ai.mit.edu>
Errors-To: listmaster@www0.cern.ch
Date: Fri, 10 Jun 1994 21:58:14 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <19940610195318.4.JCMA@JEFFERSON.AI.MIT.EDU>
Errors-To: listmaster@www0.cern.ch
Reply-To: JCMa@reagan.ai.mit.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: John C. Mallery <JCMa@reagan.ai.mit.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Full URLs in GET
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Date: Fri, 10 Jun 1994 12:09 EDT
From: Steve Putz <putz@parc.xerox.com>
Is it too late to consider changing the HTTP protocol to allow a full URL
in GET requests? In retrospect it seems a mistake to have GET just pass
the URL fragment following the host name part. As long as we are having
URLs stand in for URNs (which we are) then we should pass them around
complete. Then we would have requests like:
GET http://host.domain/docid HTTP/1.0
I second this motion. However, I would note the spec could continue to allow
url fragments that would just be interpreted as defaulting scheme to HTTP and
host and port to the server and current port.
(or maybe GET http://host.domain/docid HTTP/2.0
or GETURL http://host.domain/docid HTTP/1.0)
rather than:
GET /docid HTTP/1.0
In addition to allowing easier merging of servers, this would also make
accessing a proxy server use the same protocol as accessing a regular
server.
Good abstraction collapse.
We can upgrade most of the servers before modifying the clients to send
full URL requests. This would be also good practice for the change that
will be required when we eventually start using real URNs.
Backward compatible under the defaulting scheme, assuming a client that wanted
a host other than the default was capable of specifying the full url.