Thanks for this PR!
We'll take a look at it during our current migration work from spray to akka-http.

PR updated to fix merge conflict from #869. Note the behaviour (documented in commit notes and as a test) resulting from having commas in cookie values.

Commas in cookie values are technically illegal according to the grammar, yet RFC6265 requires user agents to handle them and send them back as is (more notes on comma handling in cookies).

As mentioned in the commit notes, Spray currently handles a bad cookie of the form a=1,2 by throwing away all cookies; this PR will ensure all other cookies are parsed and the bad cookie is parsed as a=1. (I also have a preferred alternative which throws away the whole bad cookie - which is incompatible with treating commas as a cookie separator, as per #869 - so let me know if you'd prefer that instead.)

Anyway, this is ready to be merged; it's still a big improvement over the current state of "bad cookie" handling.

Thanks again for this PR, @ajknoll and @caspark!
(And sorry for taking so long to get back to it!)

I think this is a nice fix, which we'll definitely want to merge and port to Akka HTTP.
However, we'd need you, @ajknoll, to first accept the Typesafe CLA. This shouldn't take longer than 30 seconds.
Thanks again!

I'd like to know if the concern I voiced in #737 about

being lenient may lead to ambiguities like in #702 where we need to employ a non-standard reading of backquoted doublequotes to be able to finish parsing

is tested and addressed in this PR.

I think we also need more test coverage, discussion, and documentation what exactly to expect in the erroneous or ambiguous cases like the one reported in #869 and #702.

@jrudolph re your voiced concern, I don't think this introduces any further ambiguity.

There are tests added by this PR which demonstrate what happens when:

1. A cookie has an invalid name: the cookie with invalid name is completely discarded and other cookies are parsed properly.
2. A cookie has an invalid value (specifically, a comma in the value): everything after the comma is discarded for that cookie and other cookies are parsed properly.
   • Discarding part of the value is unfortunate but I believe it's an unavoidable consequence of the attempt to be lenient in cookie parsing by accepting commas as cookie separators introduced in CookieHeaders doesn't support separator ',' (who is used in JerseyClient)  #869 .
   • Nobody should be relying on being able to parse a cookie with a comma in its value since CookieHeaders doesn't support separator ',' (who is used in JerseyClient)  #869 was merged, as that change made all cookies be dropped if any of them had a comma in the value.
   • Like I said earlier, I would prefer to revert CookieHeaders doesn't support separator ',' (who is used in JerseyClient)  #869 instead and then drop the entire cookie if there's a value with a comma in it, as that would be consistent with the behaviour for cookies with invalid names. But that's a call for you (and presumably @sirthias ) to make as core project members.

We're happy to add any extra tests you'd like to see (@ajknoll has already offered extra property-based tests in his initial comment), discuss with other people (if you tell us who you want this discussed with), and/or update documentation (if you give us a pointer to the file(s) to update).

@caspark thanks for giving your opinions and your contribution. Adding no further ambiguity is certainly good. :)

I agree that we need to make a decision about how to proceed. I think we need to collect all cases that we have seen up to now and need to make sure we find a solution we can keep and improve on for a while.

@sirthias I've accepted the CLA. Glad to hear this is going ahead :) Please feel free to use the ScalaCheck tests as well if additional verification is needed, as suggested by @caspark.