HTTPCookie Constructor Fails to Handle Discard Attribute Properly

[secharvet]

Describe the bug
The HTTPCookie constructor in POCO fails to correctly handle the Discard attribute in HTTP Set-Cookie headers. Instead of recognizing Discard as an attribute, it incorrectly assigns it as the name of the cookie with an empty value, leading to the loss of the actual cookie data.

To Reproduce
You can reproduce this beahvior with a cookie formed like below (Discard token in cookie-av):
unitoken="{AES-256}/exampletoken="; Version=1; Path=/examplePath; Discard; HttpOnly

Expected behavior
Discard should be treated as an attribute of the cookie, not as the cookie name.

** Proposed Solution:**
Add a condition to handle Discard in the constructor similarly to how Secure and HttpOnly are handled.

** Environment:**

• POCO version: head version
• Operating System: Linux /Windows

[obiltschnig]

I don't think Discard is a valid cookie attribute, according to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie

[secharvet]

Thank you for your prompt response and for the clarification regarding the Discard attribute. I understand that it is not a standard attribute according to the official HTTP cookie specifications.

However, I recently encountered this attribute being sent by a backend Java Spring application, which caused the POCO-based C++ client to fail when parsing the Set-Cookie header. This unexpected behavior from the backend led to significant issues on the client side.

Given that non-standard attributes like Discard can sometimes appear in real-world scenarios, I would like to request if it would be possible to modify the POCO library to gracefully ignore such attributes instead of failing. This change could make POCO more robust and resilient in handling unexpected or non-standard input.

I appreciate your consideration of this request and your continued support for the POCO library.

Best regards,

[obiltschnig]

Potential fix (to allow non-standard fields): set name and value only once (if _name is empty) in the HTTPCookie constructor accepting a NameValueCollection. The cookie name/value will be the first entry in the NameValueCollection anyway.

[secharvet]

Thank you for your proposed fix. I appreciate the thoughtful approach in handling non-standard fields and ensuring the name/value is set appropriately. This will definitely help make the library more robust in handling real-world scenarios.

Looking forward to seeing this improvement in the next release!

Best regards,