Ran
|
Files
7
|
Run time
7s
|
Badge
Embed ▾
README BADGES
|
push
travis-ci
resolve #155 - fix hash key ordering bugs in rearrange bump version, document Changes, add some missing tests to the MANIFEST Squashed commit of the following: commit a68157bb6 Author: Lee Johnson <lee@givengain.ch> Date: Tue Nov 25 21:52:33 2014 +0100 sort keys in the _rearrange_params method and favour certain keys other others when a param can have several options. for example: [ 'BAR','FOO','BAZ' ] will be sorted alphabetically, but should we want to 'FOO' to always be favoured over any other option if it is provided then we need to add it to the regexp in the sort of the keys so when a user passes in: -foo => 1 -baz => 2 -bar => 3 then -foo will be taken as the canonical option, but if -foo is not passed in then we sort the options alphabetically meaning the -bar option would be taken this is relevant for the [ 'TYPE','CONTENT_TYPE','CONTENT-TYPE' ] set of params as passing through both -type and -content-type and additionally -charset leads to hash key ordering bugs meaning the Content-Type output in header is inconsistent. ref: GH #155 commit 18a10cbd0 Author: Lee Johnson <lee@givengain.ch> Date: Tue Nov 25 15:17:00 2014 +0100 failing test case(s) for #155 - rearrange hash key ordering bugs if i push this branch out it should fail on the travis CA server, lets see if that happens... it would seem there are still hash key ordering bugs when it comes to calling the rearrange function in CGI::Util as passing a hash through to the header method, with all three possible arguments for the content type: '-charset' => 'UTF-8', '-type' => 'text/html', '-content-type' => 'text/html; charset=iso-8859-1', shows an inconsistent output for the Content-Type header. ideally you shouldn't do that, but when you do *we* should be consistent in what we ou... (continued)
793 of 907 relevant lines covered (87.43%)
115.12 hits per line
Coverage | ∆ | File | Lines | Relevant | Covered | Missed | Hits/Line |
---|