Sigh. I haven't had time to read the whole draft yet....
Yes, 303 looks useful, except that it requires another request. So maybe
having a new header that mimics 303 would be good. But the question of
which method to use remains.
>
> >Beyond that I think the "correct" behavior is undefined. So I'm trying
> >to define it.
> >
> >Some questions that come up are:
>
> I'll answer these question working from the 302 semantics in the 1.1
> draft spec.
>
> >1) What should the method be for the redirected request?
>
> POST (or whatever other method T1 got).
>
> >2) If the method should indeed be POST, where does the content come from?
> >(POST requires Content-Type and Content-Length headers.)
>
> The content should be identical to the content that was offered to T1.
I think that's debatable, at least. You might presume that T1 already
completely processed the input. OTOH, it provides more flexibility if
both T1 and T2 can read the input. Perhaps T1 should output a
Content-length: 0 header if it actually processes the input. In any
case, it's easiest to explain that each CGI sees the same environment.
>
> >3) Should there be a way for a CGI to specify the method to use with a
> >redirection? If yes, only for local URLs, or for full ones, too?
>
> For user agent processed redirection, you can already specify the
> method by using either 302 or 303 in the Status: cgi-header (at least
> under NCSA 1.2 you could, I don't know if this is a universal CGI
> feature).
I don't see that in the current CGI spec. You can specify status code
and comment, but not method. (In general why would you specify method
in a status line, anyway?)
>
> For locally processed redirection, see my comments above.
Presumably if you could specify a method in Status (and I don't think
you can, at least not now), you could use that for local processing, too.
[...]
Dave Kristol