Fwd: Zinc HTTP Components: Zinc-HTTP-SvenVanCaekenberghe.116.mcz

> From: [hidden email]
> Date: 13 Jan 2011 14:39:04 GMT+01:00
> To: [hidden email], [hidden email]
> Subject: [SPAM] Zinc HTTP Components: Zinc-HTTP-SvenVanCaekenberghe.116.mcz
> Reply-To: [hidden email]
>
> Sven Van Caekenberghe uploaded a new version of Zinc-HTTP to project Zinc HTTP Components:
> http://www.squeaksource.com/ZincHTTPComponents/Zinc-HTTP-SvenVanCaekenberghe.116.mcz
>
> ==================== Summary ====================
>
> Name: Zinc-HTTP-SvenVanCaekenberghe.116
> Author: SvenVanCaekenberghe
> Time: 13 January 2011, 1:39:01 pm
> UUID: a102bbdc-8185-41b0-afa2-4d0af8f2557a
> Ancestors: Zinc-HTTP-SvenVanCaekenberghe.115
>
> changed the redirect behavior for POST/PUT requests: the common practice is to turn these into GET request, see ZnUserAgent>>#method:for:headers:data:imit: and ZnUserAgent>>#prepareRedirect:

> My interpretation of what is intended by 303 is that server is saying
> that the resource requested by the POST has been found (or generated)
> and may be obtained by GETting the URI in the Location header field.
>
> This is in fact what happens all the time in Seaside. The POST request
> performs the callbacks, essentially changing the server state, and
> returns 302. The client then does a GET to retrieve a page that
> reflects the changed server state.  Seaside should probably return 303
> to be in compliance with the spec, but pre HTTP 1.1 browsers may not
> recognize 303, so I guess that's why it is like it is.
>
> I think the 303 required behavior is clear. ZnHttpClient should do a
> GET after receiving a 303 response. 302 is less clear because of the
> incorrect behavior of most browsers. For 302 I suppose a setting would
> make sense to allow either the common browser behavior or the strict
> interpretation of the specification behavior.
>
> Regards,
> TF
>
> RFC 2616 Excerpt:
>
> 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.
>
> On Wed, Jan 12, 2011 at 10:44 AM, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> On 12 Jan 2011, at 19:03, Tony Fleig wrote:
>>
>>> Oops.
>>>
>>> My reply escaped before I was finished.
>>>
>>>>> 1. It is my understanding that many browsers respond to a 302/303
>>>>> response from a POST with a following GET to the address specified in
>>>>> the 302/303 Location header rather than repeating the POST with its
>>>>> payload as is done in ZnHttpClient. (See
>>>>> http://en.wikipedia.org/wiki/HTTP_303).
>>>>
>>>> I'll have to study/think about that for a while, it depends on what the specs says. It doesn't make much sense for an automated client to do a GET I think. What would you suggest ?
>>>
>>> RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) says
>>>
>>> 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.
>>>
>>> so I think we should do a GET ;) .
>>>
>>> Regards,
>>> TF
>>
>> OK, it is in the spec then but only for 303 ?
>>
>> But suppose you programmatically try to POST something somewhere and the server tells you to do that on another URL, if you then GET that URL, you haven't fullfilled the original goal of posting something somewhere. As a human, you will probably see another form and start over.
>>
>> Anyway I think it is an edge case (unless you have a real usecase), we could maybe make it an option/setting ?
>>
>> Sven
>>
>