redirect with status code 307 (for POST)

[Colin]

Hello,

I'm working on some REST style webservices and trying to use the
UrlRewrite tool to help map some old urls to the new ones. It seems
like the perfect tool for this.

What I need to do is return a redirect status code when the client
POSTs data to certain URLs. I want the client to re-POST the data to
the new URL, and my understanding from wikipedia is that HTTP status
307 instructs the client to resubmit its request to the new Location
using the same method (eg, do POST again, do not change to GET.)

I can't get UrlRewrite ver 2.6 to return 307. I've tried "permanent-
redirect", "redirect", and "temporary-redirect" but they return
statuses 301, 302, and 302, respectively. When wget receives these
statuses in response to a POST it always uses GET for the new Location
(not what I want.)

I have two questions:
1. Does result 307 actually instruct clients to retry their request
using the same method?
2. Is there a way to get UrlRewrite to return status 307?

Also, this redirect is cross-context so I cannot try "forward".

thanks,
Colin

[Wim De Smet]

Hi,

On Tue, Nov 3, 2009 at 1:04 AM, Colin <coli...@gmail.com> wrote:
> I can't get UrlRewrite ver 2.6 to return 307.  I've tried "permanent-
> redirect", "redirect", and "temporary-redirect" but they return
> statuses 301, 302, and 302, respectively.  When wget receives these
> statuses in response to a POST it always uses GET for the new Location
> (not what I want.)

I think "redirect" could work, but I'm not sure. Are you sure you're
using a version of the servlet API that supports 307?

Version 3.2 is plenty stable btw, I'd recommend upgrading.

> I have two questions:
> 1.  Does result 307 actually instruct clients to retry their request
> using the same method?

It should. But keep in mind that POST after POST has always been a bit
buggy and is only supposed to work on HTTP/1.1 clients. How about
proxying the request? I think that might work.

> 2.  Is there a way to get UrlRewrite to return status 307?

Have a look at the <run> method, it allows you to get at the
HttpServletResponse so you can set the status yourself. Not very
elegant, but I'm pretty sure it'll work.

regards,
Wim

[Avlesh Singh]

> I have two questions:
> 1.  Does result 307 actually instruct clients to retry their request
> using the same method?

It should. But keep in mind that POST after POST has always been a bit
buggy and is only supposed to work on HTTP/1.1 clients. How about
proxying the request? I think that might work.

There is a SLIGHT misunderstanding here. Status code 307 is NOT expected to work as described in the thread. Underneath is a short snippet from W3 RFC on status codes. This is what it says on the 3XX series -

This class of status code (3XX) indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.

For more read here - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Bottomline, the redirect request can ONLY be GET or HEAD. This is the harsh realty of life!

2.  Is there a way to get UrlRewrite to return status 307?

Nope. Not right now. But based on the description, I don't think you need it.

More questions?

Cheers
Avlesh

[Wim De Smet]

Hi,

On Thu, Nov 5, 2009 at 5:24 AM, Avlesh Singh <avl...@gmail.com> wrote:
>> > I have two questions:
>> > 1.  Does result 307 actually instruct clients to retry their request
>> > using the same method?
>>
>> It should. But keep in mind that POST after POST has always been a bit
>> buggy and is only supposed to work on HTTP/1.1 clients. How about
>> proxying the request? I think that might work.
>
> There is a SLIGHT misunderstanding here. Status code 307 is NOT expected to
> work as described in the thread. Underneath is a short snippet from W3 RFC
> on status codes. This is what it says on the 3XX series -
>
>> This class of status code (3XX) indicates that further action needs to be
>> taken by the user agent in order to fulfill the request. The action required
>> MAY be carried out by the user agent without interaction with the user if
>> and only if the method used in the second request is GET or HEAD. A client
>> SHOULD detect infinite redirection loops, since such loops generate network
>> traffic for each redirection.
>
> For more read here - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>
> Bottomline, the redirect request can ONLY be GET or HEAD. This is the harsh
> realty of life!

Actually I think you're missing an important modifier here: "without
interaction with the user". What the standard says is that redirect
works for any type, but in the case of a 307 POST the user client is
not allowed to redirect without asking for user confirmation. POST
after POST does indeed work AFAIK. It just doesn't work very well or
very consistently. If I'm not mistaken IE6 doesn't ask for
confirmation, but most other browsers will. I haven't tested it in a
while.

regards,
Wim

[Avlesh Singh]

Actually I think you're missing an important modifier here: "without
interaction with the user". What the standard says is that redirect
works for any type, but in the case of a 307 POST the user client is
not allowed to redirect without asking for user confirmation. POST
after POST does indeed work AFAIK. It just doesn't work very well or
very consistently. If I'm not mistaken IE6 doesn't ask for
confirmation, but most other browsers will. I haven't tested it in a
while.

You misread it Wim. I'll try to be visual and explain it -

Request-1 (GET/POST/HEAD) -> Location: URL-2; Code: 307 -> Request-2 (ONLY GET/HEAD)
If Request-1 is POST, then a redirect would also ask for a user confirmation (this is how 307 differs from 302/303, wherein the requested resource is treated as MOVED and the client is NOT asked to confirm)

Moreover, the 3xx response is supposed to be headers only with no body. State-2 in the visual above CANNOT have a body. In this case you anyways have no way of passing the post data back to the client. And even if you do, they are NOT supposed to be used. As I earlier said redirects can only be GET/HEAD.
                   
Clear?

Cheers
Avlesh

[Wim De Smet]

On Thu, Nov 5, 2009 at 12:10 PM, Avlesh Singh <avl...@gmail.com> wrote:
>> Actually I think you're missing an important modifier here: "without
>> interaction with the user". What the standard says is that redirect
>> works for any type, but in the case of a 307 POST the user client is
>> not allowed to redirect without asking for user confirmation. POST
>> after POST does indeed work AFAIK. It just doesn't work very well or
>> very consistently. If I'm not mistaken IE6 doesn't ask for
>> confirmation, but most other browsers will. I haven't tested it in a
>> while.
>
> You misread it Wim. I'll try to be visual and explain it -
>
> Request-1 (GET/POST/HEAD) -> Location: URL-2; Code: 307 -> Request-2 (ONLY
> GET/HEAD)
> If Request-1 is POST, then a redirect would also ask for a user confirmation
> (this is how 307 differs from 302/303, wherein the requested resource is
> treated as MOVED and the client is NOT asked to confirm)

I reiterate, I do not think I am misreading it. The RFC specifically
allows for a 307 to result in a POST request, namely here:
"If the 307 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued. "

In principle, even a 301 should be able to redirect to a POST in the
second request. The real-world behaviour is for browsers to convert
the request into a GET though (see the note). A 303 was specifically
introduced to allow the server to indicate the request should be
converted to a GET. A 307 on the other hand, does not allow a client
to change the request method.

> Moreover, the 3xx response is supposed to be headers only with no body.
> State-2 in the visual above CANNOT have a body. In this case you anyways
> have no way of passing the post data back to the client. And even if you do,
> they are NOT supposed to be used. As I earlier said redirects can only be
> GET/HEAD.

The client is supposed to re-present the same post parameters to the
new location. I never said the server returned those parameters in
some way.

>
> Clear?

I really don't see how I'm misreading it. I think you simply have it
wrong in this case.

regards,
Wim

[Colin]

On Nov 4, 3:03 am, Wim De Smet <krom...@gmail.com> wrote:

> > I have two questions:
> > 1.  Does result 307 actually instruct clients to retry their request
> > using the same method?
>
> It should. But keep in mind that POST after POST has always been a bit
> buggy and is only supposed to work on HTTP/1.1 clients. How about
> proxying the request? I think that might work.
>

Can you explain what you mean by "proxying the request"?

thanks,
Colin

[Wim De Smet]

The <to type="proxy">. I have not used it myself before, but it looks
like it does what you want it to do.

regards,
Wim

[Avlesh Singh]

I really don't see how I'm misreading it. I think you simply have it wrong in this case.

I'll try and put up a sample on the web today.

Cheers
Avlesh

[Wim De Smet]

How about:
http://www.andypemberton.com/sandbox/prg/

I tried it with a 307. In firebug I'm seeing 2 POSTs and the required
browser behaviour (confirmation before second POST).

regards,
Wim

[Avlesh Singh]

You are right, Wim. The behavior turned out to be contrary to my belief and understanding of the 307 status code. I tested it myself to verify. The only problem is that command line agents (wget, curl etc) still don't "re-submit" the post data to new url. This led to the misconception, I initially had.

I will shortly add a ticket to support this in the UrlRewriteFilter.

Cheers
Avlesh