RE: 301/302

Unfortunately, I am beginning to think this is exactly what we have 
done. I may totally misunderstand the situation, but if a resource has 
been permanently moved, that information is primarily of interest to 
the original client (origin client?) and it is really the task of any 
intermediate proxies to communicate that information back to the 
client. The reason, of course, is that the original client may want to 
update its record of where that resource is located. On the other 
hand, if a resource has temporarily moved, then it makes sense that a 
proxy requesting that resource be redirected to it, and that the 
corresponding entity be carried back to the original client without 
that client ever being made aware that it had moved. What I have in 
mind here something like redundant servers using redirects implement 
load balancing (where a redirect is less expensive than actually 
serving a complex or dynamic resource).

Fortunately, whichever status code it is that should be sent back to 
the original client (say 200 or 202) is likely to be returned by the 
server which received the redirected request. But still the situation 
is problematic. To take a second example, imagine a web based front 
end to a mailing list. When a user submits a subscription request, 
that request will likely be handed off to a list server which will 
potentially send a confirmation message back which must be 
acknowledged before the subscription becomes active. In such a 
situation, the natural choice of response codes is 202 not 200 
(because the request has simply been accepted for further processing). 
Now imagine that a user posts a subscription request by way of a 
proxy. If the response comes back with a status code of 202, then the 
proxy will be relaying end to end information using a response code 
that is supposed to represent hop by hop information. In this case, 
everything works, even though it is a bit kludgy. With 301/302/307, 
though, the situation is more problematic.

===
Gregory Woodhouse
San Francisco CIO Field Office - Infrastructure
Gregory.Woodhouse@med.va.gov

----------
From:  John Franks [SMTP:john@math.nwu.edu]
Sent:  Friday, September 05, 1997 12:22 PM
To:  Woodhouse, Gregory
Cc:  Roy T. Fielding; http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Subject:  Re: 301/302

[...]

I hope I am wrong, but we seem to have painted ourselves in a corner
here.  On the one hand we have decided that the client's version
should not be communicated to the origin server when there are 
proxies
(all version information is hop-by-hop).  And on the other hand we
have created end-to-end headers (e.g. 303/307) which are not
reasonably handled by HTTP/1.0 clients.  It seems that if there is no
end-to-end version information we can't have new end-to-end headers
that will break on HTTP/1.0 clients.

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Monday, 8 September 1997 06:38:29 UTC