HttpResponse.set_cookie(secure=False) still sets secure cookies

[Marty Alchin]

Currently, set_cookie() sets the secure attribute on the outgoing cookie if it's anything other than None, but since the secure attribute on cookies doesn't actually use a value, it gets sent out as secure any time any value is set on the cookie. This means that using secure=False results in a secure cookie. While it's still possible to set a non-secure cookie by simply omitting the secure argument entirely, the current behavior seems counter-intuitive.

>>> from django.http import HttpResponse
>>> response = HttpResponse()
>>> response.set_cookie('a')
>>> response.set_cookie('b', secure=False)
>>> response.set_cookie('c', secure=True)
>>> print response.cookies
Set-Cookie: a=; Path=/
Set-Cookie; b=; Path=/; secure
Set-Cookie; c=; Path=/; secure

[Marty Alchin]

Changed set_cookie() to take secure=False and to only set it on the cookie if it evaluates to True

[Malcolm Tredinnick]

Does more than is necessary, but the rewrite is useful, too. Removing that replace() call just for the benefit of max-age isn't bad and we aren't going to be adding another 10 parameters here anytime soon, so the scaling of all the if-blocks isn't an issue.

[Gary Wilson]

(In [7204]) Fixed #6657 -- Don't set secure attribute on cookie if secure=False is passed, thanks Gulopine.

[Mariusz Felisiak <felisiak.mariusz@…>]

In 15c5875:

Refs #6657 -- Corrected HttpResponse.set_cookie()/set_signed_cookie() signatures in docs.

[Mariusz Felisiak <felisiak.mariusz@…>]

In 3ab7de01:

[3.0.x] Refs #6657 -- Corrected HttpResponse.set_cookie()/set_signed_cookie() signatures in docs.

Backport of 15c5875e693cc972c996a921560624c355ab8fdd from master