Stop emailing me On Nov 14, 2017 12:08 PM, "AmazonReward Alert" < debian.a...@manchmal.in-ulm.de> wrote:
> Message for mario > > > <http://lavishjob.com/cl/r-S5LNS7MEGC4S143KDS1CK7ISE3NS0S0S0S15S2SBSCCS21FS1GMSA> > > > <http://lavishjob.com/cl/ua-S5LNS7MEGC4S143KDS1CK7ISE3NS0S0S0S15S2SBSCCS21FS1GMSA> > > > <http://lavishjob.com/cl/op-S5LNS7MEGC4S143KDS1CK7ISE3NS0S0S0S15S2SBSCCS21FS1GMSA> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Source: ruby-http-parser.rb Version: 0.6.0-3+b3 Severity: serious Tags: > upstream Dear Maintainer, your package build-depends on http-parser, and a > new version of that one has been around for a while. Even before eventually > uploading last night I already saw a problem in the test suite of your > package. However, due to a fault on my side, the new http-parser went to > unstable instead of experimental. So this increases the pressure for your > package, sorry about that. With http-parser 2.7.1, one test fails: 1) > HTTP::Parser should parse request: line folding in header value > Failure/Error: expect(@headers).to eq(test) expected: > {"Line1"=>"abcdefghijklmno qrs", "Line2"=>"line2\t"} got: > {"Line1"=>"abc\tdef ghi\t\tjkl mno \t \tqrs", "Line2"=>"line2\t"} (compared > using ==) Diff: @@ -1,3 +1,3 @@ -"Line1" => "abcdefghijklmno qrs", +"Line1" > => "abc\tdef ghi\t\tjkl mno \t \tqrs", "Line2" => "line2\t", # > ./spec/parser_spec.rb:347:in `block (4 levels) in ' If I understand > correctly, this is taken from spec/support/requests.json line 445 and 457f. > While doubtlessly http-parser changed the behaviour, I'm not sure yet > whether this wasn't rather about fixing bugs - bugs the test in > ruby-http-parser.rb relied upon. However, HTTP header line folding is > complicated and actually also deprecated in RFC 7230. Reading that one and > also the older description in RFC 2616 I guess there a too many freedoms to > expect a certain result. Also it seems http-parser 2.7.1 does unfolding in > a ... surprising manner. Now, quite frankly, my main interest is a sound > solution. Otherwise, I'm not keen on legal discussions, especially when > it's about a deprecated feature like this one. It's my job to sort these > things out with http-parser upstream but since I'm not sure how long this > will take: Would you mind disabling or relaxing the test on your side for > the time being? You might as well upgrade the test to the one in > http-parser/test.c¹ which is where obviously it was taken from in the first > place - but I'd expect this to change again soon. Sorry for the mess, and > kind regards, Christoph ¹ > https://github.com/nodejs/http-parser/blob/master/test.c > (line 614)
