This provides what I'd call a temporary fix, to unbust the tests and get the Rakudo release going.
The proper fix would require re-designing portions of the module, including user-facing methods that currently use hashes to pass data for which maintained order is desired.
Fixes https://github.com/rakudo/rakudo/issues/1880 Fixes #197 Fixes #199 Kludges #201
Fixes newly failing tests due to hash ordering now being
randomized in Perl 6, to prevent potential DoS attacks.
The module's design uses hashes to pass data for which ordering
is desired, but not required. So the proper fix would be a
larg-ish redesign that preserves the ordering of this data.
The fix simply sorts the data by keys, destroying original order,
but preserving an order, so that, for example, tests receive
predictable output.
Two pieces are affected:
1) Order of HTTP headers[^1]: The RFC says[^2] order doesn't
matter, but there's some user demand[^3] for preserving the
ordering for third party systems.
2) Order of Multi-Part form data: the HTML spec says[^4] the order
of the parts represents the order the elements appear in the
HTML. Looking at the .add-form-data method, I see they're passed
via a hash, so order information is not available to the module
from the very start and a differnt interface would be needed to
make it available.
This provides what I'd call a temporary fix, to unbust the tests and get the Rakudo release going.
The proper fix would require re-designing portions of the module, including user-facing methods that currently use hashes to pass data for which maintained order is desired.
Fixes https://github.com/rakudo/rakudo/issues/1880 Fixes #197 Fixes #199 Kludges #201 Fixes newly failing tests due to hash ordering now being randomized in Perl 6, to prevent potential DoS attacks.
The module's design uses hashes to pass data for which ordering is desired, but not required. So the proper fix would be a larg-ish redesign that preserves the ordering of this data.
The fix simply sorts the data by keys, destroying original order, but preserving an order, so that, for example, tests receive predictable output.
Two pieces are affected: 1) Order of HTTP headers[^1]: The RFC says[^2] order doesn't matter, but there's some user demand[^3] for preserving the ordering for third party systems. 2) Order of Multi-Part form data: the HTML spec says[^4] the order of the parts represents the order the elements appear in the HTML. Looking at the .add-form-data method, I see they're passed via a hash, so order information is not available to the module from the very start and a differnt interface would be needed to make it available.
[1] https://github.com/sergot/http-useragent/issues/201 [2] https://tools.ietf.org/html/rfc2616#section-4.2 [3] https://github.com/sergot/http-useragent/pull/200#issuecomment-393671547 [4] https://www.w3.org/TR/html4/interact/forms.html#h-17.13.4