eZ Community » Forums » Developer » Wrong HTTP redirect status code...
expandshrink

Wrong HTTP redirect status code returned when posting collected info

Wrong HTTP redirect status code returned when posting collected info

Wednesday 20 January 2010 4:24:33 pm - 2 replies

When posting collected info (ActionCollectInformation) successfully a 302 HTTP redirect is done to the collected info page. I belive a 303 redirect should be done instead because the method of the request is changed. Here are the reasons...

RFC2616 states for 302 rediretcs:

 Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. The status codes 303 and 307 have
      been added for servers that wish to make unambiguously clear which
      kind of reaction is expected of the client

and for 303:

 The response to the request can be found under a different URI and
   SHOULD be retrieved using a GET method on that resource. This method
   exists primarily to allow the output of a POST-activated script to
   redirect the user agent to a selected resource. The new URI is not a
   substitute reference for the originally requested resource. The 303
   response MUST NOT be cached, but the response to the second
   (redirected) request might be cacheable.

This can produce problems in real life e.g. when you want to post the collected info using ajax calls - the responses are not handled correctly.

Can someone form th eZ crew confirm that this is a bug?

Wednesday 20 January 2010 11:13:31 pm

Interesting... have you ever seen some problems caused by this?

Thursday 21 January 2010 1:02:15 am

Well, this thread is motivated by a problem that I have experienced, it happened exactly like I described:

- I wanted to post the collected info using ajax calls, and the responses were not handled correctly

I'm not sure if this redirect "bug" caused the error (I'm still debugging it), but I came accross this "bug" in the debugging process.I'll try to find out if this is the cause of my problem, but still it would be nice to follow the standards.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from