W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: 301/302

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Fri, 05 Sep 1997 18:59:32 -0500 (EST)
To: kweide@tezcat.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <01INALF4KBAA0000A1@SCI.WFBR.EDU>
Klaus Weide <kweide@tezcat.com> wrote:
>On Fri, 5 Sep 1997, Roy T. Fielding wrote:
>
>> That's pretty good, but I'd suggest a few tweaks ...
>> 
>> 10.3.3 302 Found             ["Found" was the original 302 reason-phrase]
>
>"Found" never made much sense to me...

	It means that the desired resource can be Found at the URL
pointed to by the Location header, and that's where you should try
to GET it (but Note: one can't be certain that a conversion to GET will
be performed by all versions of all UAs).  Let's stop beating a dead
horse.


>But extensibility of status codes is supposedly built into the protocol.
>RFC 1945 6.1.1 (and very similar in 2068):
>
>   HTTP status codes are extensible, but the above codes are the only
>   ones generally recognized in current practice. HTTP applications are
>   not required to understand the meaning of all registered status
>   codes, though such understanding is obviously desirable. However,
>   applications must understand the class of any status code, as
>   indicated by the first digit, and treat any unrecognized response as
>   being equivalent to the x00 status code of that class, with the
>   exception that an unrecognized response must not be cached.
>
>So a HTTP/1.0 client which doesn't know about 303 should treat it like
>300, which in turn (RFC 1945) "should include an entity containing a
>list of resource characteristics and locations from which the user or
>user agent can choose the one most appropriate."  302 responses
>normally have a brief HTML text with a link to follow the direction
>manually, that wouldn't be different for 303.  I don't know how many
>HTTP/1.0 user agents actually do display the contents of a 303
>response, but if they don't it is arguably a case of a "broken
>browser".

	This doesn't address the problem that 300 can include a Location
header, and the current draft doesn't specify what to do about the
method if it is not safe.  I think this should be addressed explicitly.
If the method is not GET or HEAD, the UA should not use the Location but
instead present the body.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
Received on Friday, 5 September 1997 16:07:08 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:00 EDT