- From: Klaus Weide <kweide@tezcat.com>
- Date: Thu, 28 Aug 1997 21:49:01 -0500 (CDT)
- To: "David W. Morris" <dwm@xpasc.com>
- Cc: Lou Montulli <montulli@netscape.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Thu, 28 Aug 1997, David W. Morris wrote:
> On Thu, 28 Aug 1997, Lou Montulli wrote:
>
> > How is this issue going to get resolved? This tread died out almost a month
> > ago yet there is no solution yet. The current situation is unworkable.
>
> I thought we had reached concensus that 302 would be redefined to current
> practice that 301 and 303 were correctly defined AND that a new
> code (307) would mean what 302 currently says.
>
> But I don't recall anyone declaring concensus or providing actual proposed
> wording changes.
The message where I proposed what is summarized above is at
<URL: http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0402.html>.
(For some reason it doesn't show up immediately when one follows the
links into the archive from the Issues Page.) There were several replies
that indicated agreement.
If the people present in Munich came to a different consensus, I would
very much like to know why. The Issues Page currently has "Consensus at
IETF seems to be to swap the codes, rather than making the protocol
cruftier." Can someone explain why it is better to make 303 as currently
specified unusable, rather than just adjusting the specification as
much as necessary (as dictated by reality)?
My guess is that nobody was present who wants to implement or use the
"true redirection" functionality (what 302 currently says, proposed for
307). Maybe there is nobody using it, and there will never be an
implementation. In that case it would be more honest to just completely
get rid of it, instead of just pushing it around, first to 302, then to
303. Specifying something for 303 which won't get used, and in addition
is completely contrary to RFC 2068, doesn't reduce cruft.
If "true" (but temporary) redirection is to be retained as a useful
feature of the protocol - I assume everyone who wants to implement it
would prefer to use a new, "clean" status code, rather than one for which
at least one RFC has specified the exact opposite.
Klaus
Received on Thursday, 28 August 1997 19:52:35 UTC