-=| John Dunlap, 16.06.2015 18:28:20 -0400 |=-
> Remembering that hash key order is supposed to be random, I changed
> it to
> this for testing purposes:
> ==== BEGIN ====
> sub set_cookie {
> my ($this, $args) = @_;
> my $values;
>
> assert_hashref($args);
>
> $values .= sprintf("session=%s; ", $args->{'session'});
> $values .= sprintf("path=%s; ", $args->{'path'});
>
> # Set the header
> $this->apache->headers_out->{'Set-Cookie'} = $values;
> }
> ==== END ====
>
> Since making that change, I haven't been able to make the Debian 8
> environment misbehave.
You may want to try with the reverse order and see if the browser
(mis-)behaves reproducibly.
> So, in answer to my own questions, my current theory
> is as follows:
> 1) The browser may not be respecting the Set-Cookie header if it's
> expecting the values to appear in a specific sequence(Though I don't know
> why it would care).
According to RFC6265[1], the order of the a=b pairs in the Set-Cookie
header is important. The first pair defines the name and the value of
the cookie, the rest are attributes.
[1] http://tools.ietf.org/html/rfc6265#section-4.1
* 'Set-Cookie: session=boo; path=/' is setting a cookie named
'session' with a value of 'boo' with attributes 'path=/'
* 'Set-Cookie: path=/; session=boo' sets a cookie named 'path' with
a value of '/' and attributes 'cookie=boo' -- quite a different
thing.
> 2) It's possible that, in this specific scenario, there existed
> a bug in the version of Perl which shipped with Debian 7 which
> didn't properly randomize the hash key order and that, by pure
> coincidence, they were being written into the cookie in the sequence
> which the browser expected.
That's right. Hash randomization was improved in perl 5.18. Debian
7 ships with perl 5.14.2, and Debian 8 with perl 5.20.2.
> 3) The behavior on Debian may be inconsistent because the version of
> Perl which shipped with it correctly randomizes the key order so
> that the order of the values in the session cookie *sometimes*
> appear in the sequence which the browser is anticipating.
I think this is correct. Add to this that the hash key order is
persistent within the process, so you have to hit another apache child
in order to "roll the dice" again.
HTH,
dam
