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

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.