On Mon, 2 Apr 2012, Andrei Cipu wrote:

> First of all, I don't think of this as a blatant violation, but rather a
> bending of the spec. That's why I believe the server I'm working with might
> not be the only one implementing it, thus making the patch potentially
> useful to other libcurl users (but I have no proof for this).

In my view, a SHOULD is short for "this is the way to do it unless you have a
really really good reason not to", and I can't think of such a reason here.
But OK, I'll give in since I understand this is a server and another client
that made it like this.

> To answer your question, the behavior appears when the server is talking
> (HTTP) to a dedicated client, so I believe the answer is "because they can".
> I cannot test that particular server using a full browser or give you any
> other data points, but I suspect the browser will follow the rfc. Very
> likely, the message exchange with the browser will be slightly different.

So okay, let's add the option for 303 as well - after all it is very easy and
comes with hardly any cost. But then I have some minor additional requests for
the patch:

1 - please also update the documentation (see docs/libcurl/symbols-in-versions
     too)

2 - I think we can switch to using a bitmask internally now since having three
     different booleans for this turns inconvenient I think.

3 - Not strictly required, but please consider adding a test case that
     verifies this new bit. There should be existing 301/302 test cases to
     get inspiration from.

4 - Add a command line option to curl for this?

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