Re: Host: vs. Orig-URI: w/ %%

On Fri, 22 Sep 1995, Dave Kristol wrote:

> I believe that's what Dave Morris originally said.  In short, the
> Orig-URI header should be the full URL selected by the user agent.  And
> %% stands for what the origin server would see as the URL in the
> request.  So if there are parameters and a fragment, the Orig-URI
> header would be as you show.

If we are still in 'no compromise' mode then my 'vote' is for 
host (by any name) and *REQUIRED*. 

However, I do believe there is
value in being able to track exactly what the user originally 
requested. To that end I suggested the %% compression notation for
the Orig-URI: header.  In short, the point is that the Orig-URI 
would, when combined with the request URL if %% is present, provide
the final serving server with the original URI.  Any time the
request URL is manipulated as the request transitions thru the
network, an Orig-URL field with %% must be updated. The obvious update
is for the proxy situation where the initial request URL was the
full URI. In that case we would have:

GET http://abcdefg.com:port/urlpath/... HTTP/1.1
Orig-URI: %%

Or the Orig-URI could be omitted since this example doesn't include
client side parameters such as the #fragment. After the proxy
handles the request we would need:

GET /urlpath/... HTTP/1.1
Orig-URI: http://abcdefg.com:port%%

A second intermediate proxy, under these simple rules would result in
a full Orig-URI: value.

Of course, if this is combined with the proposal the the full URL
always be included on the GET then Orig-URI only need carry the
fragment in the normal case (useing the %% compression). Proxies 
wouldn't normally change the request url and yet we have defined
a mechanism to insure that the original user request is recorded.

Dave Morris

Received on Saturday, 23 September 1995 16:09:18 UTC