Re: Redirection inherits METHOD?

On Sun, 18 Jun 1995, Henrik Frystyk Nielsen wrote:

> 
> > Just wondering what the feeling is on a redirection inheriting the 'method'
> > of the original request is.
> > 
> > Say i've got a form being posted, and issue a redirection to a normal
> > document (not another CGI script).
> > 
> > Should the form contents be reposted to the new destination?  Some of the
> > language in section 6.2.2 seems to imply this, but in other cases it
> > doesn't make sense to inherit them.
> 
> stuff deleted
> 
> > I think this was discussed before, but I thought the outcome was 'yes
> > redirect using POST', but I just ran into a form that redirects to a static
> > page, and the server fails to serve the document when you 'POST'.  I can't
> > get to the working group pages for some reason to check the archives
> > either.
> 
> I think the comment then was that the normal behavior is to change method from
> POST to GET on a redirect. However, I am strongly inclined to say that a 
> method _should_be_ inherited on a redirect, even though this might break some
> setups that depend on it. The reason is that I don't want POST to be limited
> to sending form data over the wire.
[...] 
> However, I can see situations where a change in method would be useful, but for
> this I suggest that we "re-introduce" the '303 Method' header and find a syntax
> that fits.
> 
> Again, as the current practice is not according to preferred practice, I strongly
> suggest that the latter is to go into the HTTP spec.

It seems to me that default should be to inherit the method. Then define
an option to alter the method. (is that '303 Method'?). There should
probably be a SAFE set of method changes which the UA could simply
perform (POST -> (GET | HEAD) and others which would require the 
end user to approve (* -> DELETE) some or all of the time. Even 
inheriting the METHOD might require approval on some re-directs.
Alternatively, the server(s) which did the redirect might be
identified to the server receiving the redirected request.. I'm
beginning to sense some real security nightmares best left to the
next version of the standard for carefully thoughout specification.

I can even appreciate why current practice/standard chose the easy
safe route and turn all requests into something 'safe'.

Dave Morris

Received on Monday, 19 June 1995 10:43:53 UTC