Order of received headers not preserved #201
Comments
zoffixznet
added a commit
to zoffixznet/http-useragent
that referenced
this issue
Jun 18, 2018
Fixes sergot#197 Fixes sergot#199 Kludges sergot#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] sergot#201 [2] https://tools.ietf.org/html/rfc2616#section-4.2 [3] sergot#200 (comment) [4] https://www.w3.org/TR/html4/interact/forms.html#h-17.13.4
ugexe
pushed a commit
that referenced
this issue
Jun 18, 2018
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] #201 [2] https://tools.ietf.org/html/rfc2616#section-4.2 [3] #200 (comment) [4] https://www.w3.org/TR/html4/interact/forms.html#h-17.13.4
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
All the headers are being passed around in a Hash, which doesn't keep around the order in which the items were added. Rakudo implementation used to preserve the order as a limitation of hash implementation, which has been recently fixed. There are tests in the test suite that rely on the buggy, non-randomized order and they're now failing (#197 #199 #200)
While RFC 2616, section 4.2 says order of headers with different names doesn't matter, it's been suggested it should be preserved as some tools base their decisions based on the order.
Looking at the code, the problem is actually in the module itself and not the tests. The
HTTP::Header.new,HTTP::Header.init-field, andHTTP::Response.newtake headers via a Hash, and would need to be redesigned to include a multi that accepts an ordered list of headers.Given the popularity of this module, in the meantime, I suggest the failing tests would be fudged to fix failures in installations and automated testing of all the modules that use this one.
The text was updated successfully, but these errors were encountered: