`Get Cookies` should support returning cookies as objects and have better logging

Currently Get Cookies returns a cookies as a string in format cookie1=value1; cookie2=value2. This isn’t very useful if you need to actually handle all cookies somehow, and the return format isn’t even documented anywhere. We should change the keyword to return cookies as a list (or ordered dictionary) of CookieInformation objects that were introduced as part of #932.

Changing keyword return value is obviously backwards incompatible, so we cannot do it without a deprecation period. I propose that in v3.1 we add an argument like return_objects=False that can be used to explicitly change the return value. This allows users to opt-in if they want to get objects. In v3.2 we could then change the argument to return_objects=True, making it possible to opt-out if needed. And in v3.3 or later the whole argument can be removed. This issue only covers adding return_objects=False (or similar), changing and removing it later require separate issues later.

Another problem in Get Cookies is that it doesn’t log anything. The beginning of the return value is logged automatically if the return value is assigned to a variable, but it would be better to log at least names and values explicitly.

---

UPDATE: @Mohorelien commented below that there actually is a use case for the current format in HTTP request headers. I still think having a way to return cookie information as objects is useful, but we should preserver the current functionality too. I’d also keep the current functionality as the default functionality to avoid all backwards incompatible changes. That way this change could even be done in SL 3.0 if we have time.

[pekkaklarck]

Thanks @Mohorelien for letting us know about this use case! Since the current format actually is useful, I think it’s better we leave it like it is and add an optional argument like objects=False that can be used if CookieInformation objects are needed. This simplifies things a lot as adding such functionality is not backwards incompatible and we don’t need to deprecate anything. Implementation is also so simple that this could even make it to 3.0.

[aaltat]

There seems to be real use case for the current format, we did not know that. Thank you for the input. We did have a different use case in mind and it’s seems that we have to think this little bit more.

Because there is a good use case for the current format, we should provide support for it. Either by this keyword or by some other means. But it would be good to enhance keyword to actually return cookies as an object which would provide possibly to iterate through the cookies with for loop and provide a value suitable for the RequestLibrary.