Sales pitch: use libapreq2, which gracefully handles merged cookie headers anyway.
Sent from my iPhone > On Jun 28, 2016, at 6:39 PM, Joseph Schaefer <joe_schae...@yahoo.com> wrote: > > The industry standard behavior regarding cookies is for user agents to send > at most a single cookie header, and for servers to avoid merging set-cookie > headers. The set-cookie2 header is merge able. > > Sent from my iPhone > >>> On Jun 28, 2016, at 6:14 PM, Rainer Canavan <rainer.cana...@sevenval.com> >>> wrote: >>> >>> On Tue, Jun 28, 2016 at 10:13 PM, William A Rowe Jr <wr...@rowe-clan.net> >>> wrote: >>> On Tue, Jun 28, 2016 at 2:29 PM, Rainer Canavan >>> <rainer.cana...@sevenval.com> wrote: >>>> It's not just the Cookie that's logged via %{}C that gets nonsense >>>> appended, but the cookie parser of e.g. PHP behaves the same. I think >>>> httpd could handle this better by not merging the headers or merging >>>> them in a way that is consistent with the syntax of the Cookie: >>>> response header. Since the original Cookie: header sent by the client >>>> gets corrupted by httpd, I'd even prefer dripping any additional >>>> headers over the current behaviour. >>> >>> That's not nonsense, and dropping isn't an option. You need to review >>> >>> https://tools.ietf.org/html/rfc7230#section-3.2.2 >>> >>> and stop and explain your confusion so we can assist. >> >> I've read that already. The problem is that rfc 7230 explicitly states >> that Set-Cookie >> should be treated as a special case, but does not mention the Cookie request >> header, which suffers from similar problems. I agree that sending multiple >> Cookie headers is not allowed according to rfc 6265 and that combining >> them is perfectly fine according to rfc 7230, however, it's rather >> inconvenient >> and I believe it is unlikely that the current behavior is what the >> broken clients / >> proxies intend. >> >> rainer >