On Fri, 30 Mar 2012, Andrei Cipu wrote:

> Currently libCURL assumes that if a POST request returns HTTP code 303, the
> follow-up must be a GET request. It even has a funny comment in the code:
> " doing a second POST when following isn't what anyone would want!".

Yes, the comment is indeed funny and should be removed.

> However, RFC 2616 states [1] that " a different URI [...] SHOULD be
> retrieved using a GET method on that resource" (only SHOULD, not MUST). As
> it turns out, there are servers out there that want a POST after they
> returned 303 to a previous POST request.

And there are browsers doing that as well? The "bad" 301 and 302 behaviors
were due to how things were in the early HTTP 1.0 days. 303 wasn't introduced
until HTTP 1.1 and the phrasing was quite clear IMHO. Why would anyone to
blatantly and clearly violate the spec and not obey the SHOULD? It doesn't
really make sense to me. Do you know?

A server that *REALLY* wants the client to use the same request again after a
HTTP redirect should use 307. And if they're somewhat modern and what the
"permanent" state for the redirect then 308 is your friend:

   http://tools.ietf.org/html/draft-reschke-http-status-308-07

Your patch is small and unintroducive, but I would rather first try to
understand why 303 is used here and what browsers facing this response code
do.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html