[Citadel Development] Re: 303 Status response
This would work quite nicely with my current efforts to remove all of the round-trip form submissions in the system. For example, in the message editor, we no longer submit the form when adding attachments. It is my intention to validate recipients before sending the form as well. And in the calendar view, I would like to do free/busy checking without a submit.
[Citadel Development] Re: 303 Status response
hm, it pro'lly would also straightn the code and reduce unneccesary cross-dependencies.. it should probably be 302 for 'temporarily moved' else one won't be able to post a second message ;-) Fr Jan 21 2011 04:32:36 EST von samjam @ Uncensored Betreff: 303 Status response W3C seem to have updated RCS's inlreation to the meaning and use of the HTTP 302 and 303 status responses: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html It looks like whether or not 302 or 303 is used should possible depend on the level of HTTP in the request. I would therefore like to suggest again, that where possible, citadel should not return body as a result of post, but save state and then issue a 303 to re-request the correct view. This avoids browser pain if/when the back button is used. I have no strong case to make, I merely mention it as potential best-practice. Sam 10.3.3 302 Found The requested resource resides temporarily under a different URI Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 302 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. 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. 10.3.4 303 See Other 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. The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.
[Citadel Development] 303 Status response
W3C seem to have updated RCS's inlreation to the meaning and use of the HTTP 302 and 303 status responses: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html It looks like whether or not 302 or 303 is used should possible depend on the level of HTTP in the request. I would therefore like to suggest again, that where possible, citadel should not return body as a result of post, but save state and then issue a 303 to re-request the correct view. This avoids browser pain if/when the back button is used. I have no strong case to make, I merely mention it as potential best-practice. Sam 10.3.3 302 Found The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field. The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 302 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. 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. 10.3.4 303 See Other 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. The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.
