Re: Way redirect POST? [was Re: LYNX-DEV two curiosities from IETF HTTP session.

[Foteos Macrides]

"David W. Morris" <address@hidden> wrote:
>On Wed, 10 Dec 1997, Foteos Macrides wrote:
>> That would make 305 utterly safe, and it's not obvious to me why a
>> POST or other non-safe request would ever be redirected to a proxy
>> with intention that the content be retained (it's most likely to be
>> used by scripts homologously to 302/303), so I doubt this would pose
>> a functionality problem.
>
>As a HTTP based application builder, it is quite clear to me why I want
>to redirect a POST as a POST to another server with/without proxy
>considerations. If the POST isn't redirected, all the reasons for
>using a POST method in the first place get broken IF the intent is
>to have the redirect target process the POST as submitted.
>
>In one developer community whose mailing list I follow, a request for
>how to accomplish this function comes up at least once a week ... which
>suggests to me a much higher demand since each time the request comes
>up some additional percentage of the group learns that it isn't possible
>and some other mechanism is required to forward the POSTed content to
>the processing server.
>
>I'm not proposing any changes but I wanted to make it clear that there
>is an unaddressed requirement for seamless redirection of POST requests.

        Sure, but I was referring to *one-shot* redirection of the
*browser* to use a proxy via 305.  What to do about the method (and
who should act on the redirection) could be specified via the Set-Proxy:
header for 306.  For 306, POST or PUT content could be retained, or not,
depending on its directives (assuming that a new 306 proposal is
forthcoming and its security/privacy problems are solved).  Also,
HTTP/1.1 will have 307 available for redirection to another origin
server as ultimate request target with POST or PUT content retained,
which I suspect is what's actually being sought in the discussions to
which you refer (unless you're talking about redirections to be acted
upon by an intermediate proxy, rather than the browser which initiated
the request).  If the browser already is using a proxy, the browser
must have been configured to use it (i.e., it can be presumed "safe"),
and would continue to use that proxy for the 307 redirection with POST
or PUT retained.  If you want to change the browser's proxy, or set one,
for a redirected request, plus retain an "unsafe" method, you have
"unsolved security/privacy problems" which would preclude keeping 305
in the upcoming HTTP/1.1 Draft Standard, so let's put that off to a
future draft for 306, and keep 305 for utterly safe, 303-like and
one-shot redirection by an origin server for the browser to seek the
document via a proxy.

        A proxy server doesn't process POST content (at least, not
HTTP/1.0 or HTTP/1.1 proxies).  Only an origin server (or its
script) does that.  A one-shot, 305 redirection would be to GET a
document which the origin server (or its script) has reason to
"think" has been cached by the proxy specified in the Location:
header, and if the proxy no longer has it in cache, the request will
be directed by that proxy back toward the origin server, so that the
proxy's cache will be refreshed in conjunction with filling the
browser's request, i.e., the "utterly safe" 305 is useful (and works,
based on implementation experience with Lynx), albeit that a 306 with
the originally intended, much greater functionality should still be
planned on as a new, separate draft (but *not* as a replacement or
further modification of 305).

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================