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".
On Tue, Nov 3, 2009 at 1:04 AM, Colin <colin...@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.
> > 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.
> On Tue, Nov 3, 2009 at 1:04 AM, Colin <colin...@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.
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.
> 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.
> 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
On Thu, Nov 5, 2009 at 4:19 PM, Wim De Smet <krom...@gmail.com> wrote:
> 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.
> > 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.
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.
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"?
On Thu, Nov 5, 2009 at 3:20 PM, Colin <colin...@gmail.com> wrote:
> 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"?
The <to type="proxy">. I have not used it myself before, but it looks like it does what you want it to do.
> 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.
On Fri, Nov 6, 2009 at 3:19 AM, Avlesh Singh <avl...@gmail.com> wrote:
>> 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
> On Thu, Nov 5, 2009 at 6:02 PM, Wim De Smet <krom...@gmail.com> wrote:
>> 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.
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
On Fri, Nov 6, 2009 at 1:48 PM, Wim De Smet <krom...@gmail.com> wrote:
> I tried it with a 307. In firebug I'm seeing 2 POSTs and the required
> browser behaviour (confirmation before second POST).
> regards,
> Wim
> On Fri, Nov 6, 2009 at 3:19 AM, Avlesh Singh <avl...@gmail.com> wrote:
> >> 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
> > On Thu, Nov 5, 2009 at 6:02 PM, Wim De Smet <krom...@gmail.com> wrote:
> >> 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.
|
