Anyways I agree with Bill that this isn't httpd's problem to fix. The cookie
standards are abysmal which is why some level of strictness is required as
regards the defacto httpd behavior to prevent all hell from breaking loose.
Sent from my iPhone
> On Jun 28, 2016, at 7:51 PM, Joseph Schaefer <joe_schae...@yahoo.com> wrote:
>
> Or use ssl so proxies can't monkey with the request headers.
>
> Sent from my iPhone
>
>> On Jun 28, 2016, at 7:48 PM, Joseph Schaefer <joe_schae...@yahoo.com> wrote:
>>
>> 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
>
