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
