W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

redirection issues

From: Foteos Macrides <fote@csi.com>
Date: Wed, 20 May 1998 01:33:27 -0400
Message-Id: <000701bd83b0$e66e1a20$c9d9afce@default>
To: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/133
Jim Gettys <jg@pa.dec.com> wrote regarding "New issues list published":
>As always, it is:
>Note that all issues from before last call have been moved to a
>page to reduce confusion.

 Note that Issue #he9 concerning 302 redirection in the new issues list
is not really a new "open" issue, but simply an editorial matter of
fully on the closed Issue #23 in what is now the BeforeLastCall.html
The current draft has changed the status string to "Found" and appended
"Note:" alerting readers that 302 has been changed from what was in RFCs
1945 and 2068, but the actual text has not been changed to "... [ text
302, amended to allow UAs "converting" to GET ] ...".

 I three times posted concern about 305 Use Proxy as it presently
stands in the draft allowing a proxy to redirect a POST without explicit
confirmation from the user/UA which submitted the form, which is a
serious security/privacy issue.  There still has been no discussion
this, nor is it recorded in the new issues list.  Two possibilities are
(1) require that 305 for a POST be returned to the UA which submitted
the form and not be acted upon by any interposed proxies, or (2) drop
305 together with 306 Set Proxy from the Draft Standard.  Note with
respect to the need for two independent implementations, that I dropped
active support for 305 in Lynx v2.7.2, so that the body of a 305 is
displayed to the user, and this is still the behavior in Lynx v2.8.
Restoring the behavior of acting on a 305 if the method is safe, and
prompting the user about whether to act on it for a POST, would be
simple, but I'm not personally keen on retaining 305 until/unless the
issue of what is appropriate behavior within proxy chains is resolved.

 300 Multiple Choices in the draft does not say what should be
done if the method is not GET.  Since 300 also is the default for
redirection statuses which a UA does not know, it would be a good
idea to specify what should be done in the the case of POST.  When
this issue was raised before, Koen pointed out that all existing
implementations would convert the POST to a GET, i.e., that is
universal current practice, so it shouldn't be a problem specifying
that explicitly in the Draft Standard.  In most cases, I suspect,
the UA will in fact end up showing the body of the unknown 3xx
response, and for an actual 300 it would be expecting additional
information associated with content negotiation, but whenever it
acts on a 300 rather than showing the body, it would seem that a
POST should be converted to GET (without need for user confirmation
it that conversion is done).

Foteos Macrides
Received on Tuesday, 19 May 1998 22:37:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC