Re: Merging of Multiple Cookie Headers

[Rainer Canavan]

On Wed, Jun 29, 2016 at 2:02 AM, Joseph Schaefer  wrote:
> Php's cookie parser can be more lax in treating ", " similar to "; ", that 
> would be a better avenue of redress.  Otherwise they can adopt libapreq2's 
> cookie parsing code which has much richer support for merging cookie headers 
> written to different cookie specs.

That's basically what it'll have to be, since even if this was "fixed"
in httpd, it would probably take years for this to appear in the
apache packages of any of the "enterprise" Linux distributions.
Anyway, in my opinion, the same argument regarding treating ", " like
"; " also applies to httpd (regarding %{...}c), especially since ,
isn't allowed anywhere in a cookie, but there's no point in continuing
this discussion.

rainer

Re: Merging of Multiple Cookie Headers

[Joseph Schaefer]

Php's cookie parser can be more lax in treating ", " similar to "; ", that 
would be a better avenue of redress.  Otherwise they can adopt libapreq2's 
cookie parsing code which has much richer support for merging cookie headers 
written to different cookie specs.

Sent from my iPhone

> On Jun 28, 2016, at 7:58 PM, Joseph Schaefer  wrote:
> 
> 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  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  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  
 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 
>>  wrote:
>> 
>> On Tue, Jun 28, 2016 at 10:13 PM, William A Rowe Jr 
>>  wrote:
>> On Tue, Jun 28, 2016 at 2:29 PM, Rainer Canavan
>>  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
> 

Re: Merging of Multiple Cookie Headers

[Joseph Schaefer]

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  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  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  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  
> wrote:
> 
> On Tue, Jun 28, 2016 at 10:13 PM, William A Rowe Jr  
> wrote:
> On Tue, Jun 28, 2016 at 2:29 PM, Rainer Canavan
>  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
> 

Re: Merging of Multiple Cookie Headers

[Joseph Schaefer]

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  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  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  
 wrote:
 
 On Tue, Jun 28, 2016 at 10:13 PM, William A Rowe Jr  
 wrote:
 On Tue, Jun 28, 2016 at 2:29 PM, Rainer Canavan
  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
> 

Re: Merging of Multiple Cookie Headers

[Joseph Schaefer]

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  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  
>>> wrote:
>>> 
>>> On Tue, Jun 28, 2016 at 10:13 PM, William A Rowe Jr  
>>> wrote:
>>> On Tue, Jun 28, 2016 at 2:29 PM, Rainer Canavan
>>>  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
> 

Re: Merging of Multiple Cookie Headers

[Joseph Schaefer]

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  
> wrote:
> 
>> On Tue, Jun 28, 2016 at 10:13 PM, William A Rowe Jr  
>> wrote:
>> On Tue, Jun 28, 2016 at 2:29 PM, Rainer Canavan
>>  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

Re: Merging of Multiple Cookie Headers

[Rainer Canavan]

On Tue, Jun 28, 2016 at 10:13 PM, William A Rowe Jr  wrote:
> On Tue, Jun 28, 2016 at 2:29 PM, Rainer Canavan
>  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

Re: Merging of Multiple Cookie Headers

[William A Rowe Jr]

On Tue, Jun 28, 2016 at 2:29 PM, Rainer Canavan  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.

Re: Merging of Multiple Cookie Headers

[Rainer Canavan]

On Tue, Jun 28, 2016 at 6:09 PM, Graham Leggett  wrote:
> On 28 Jun 2016, at 4:29 PM, Rainer Canavan  
> wrote:
>
>> We've observed multiple gateways, operated by e.g. AT, COLT and
>> Vodafone, that inject additional Cookie: headers into client requests,
>> such as
>>
>> Cookie: actually=from_the_client
>> Cookie: Bearer-Type=w-TCP
>> Cookie: network-access-type=UMTS
>>
>> Apache httpd merges those headers into a single, comma separated list,
>> and also appends the names and values of all Cookies set in the
>> additional Cookie Headers to the value of the last Cookie of the first
>> header. This can be seeen by logging  %{actually}C for the example
>> above, which would contain
>>
>> actually=from_the_client, Bearer-Type=w-TCP, network-access-type=UMTS
>>
>> While RFC 6265 clearly requires that User-Agents send only a single
>> Cookie: request header, I would argue that the Cookie header should be
>> treated as an exception, similar to the Set-Cookie:-response header,
>> and not be merged into a single header field. An alternative would be
>> to use "; " as a separator.
>>
>> Any thoughts?
>
> What problem are you trying to solve?


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.

rainer