Failed t/160-issue-67.t

[titsuki]

Hi

I faced the following situations.

# Failed test 'recv calls'
# at t/160-issue-67.t line 21
# expected: '1'
#      got: '9'
# Looks like you failed 1 test of 2
t/160-issue-67.t ...........
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/2 subtests
t/170-request-common.t ..... ok
t/180-mediatype.t .......... ok
t/190-issue-116.t .......... skipped: IO::Socket::SSL not available
t/200-w3-test-encodings.t .. ok
t/210-content-encoding.t ... ok
t/220-binary-content.t ..... ok
t/230-binary-request.t ..... ok

Test Summary Report
-------------------
t/160-issue-67.t         (Wstat: 256 Tests: 2 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=21, Tests=188, 67 wallclock secs ( 0.06 usr  0.07 sys + 52.83 cusr  4.03 csys = 56.99 CPU)

My environment is

$ perl6 -v
This is Rakudo version 2016.01 built on MoarVM version 2016.01
implementing Perl 6.c.

[jonathanstowe]

I'm not seeing that here, I think it must be related to the local network conditions. It appears that the test expects that the content is returned in a single chunk, and that is indeed happening here (and I guess for the majority of other people,) but for some reason you are getting it in 9 tiny chunks.

The test is there to determine that the chunked transfer is being handled correctly, however if you really are getting the response in small chunks then it is probable that there is nothing wrong with the code but rather the test is making a false assumption. It might be that we need to find a source that is guaranteed to always return a specific number of chunks.

Is there any way that you can attach the raw (that is via telnet or some other mechanism that won't try to do any processing,) response from the http://www.punoftheday.com/cgi-bin/todayspun.pl so we can work out how to adjust the test.

[titsuki]

@jonathanstowe

The following is the raw response from punoftheday.com.

$ curl -X GET --raw --verbose "http://www.punoftheday.com/cgi-bin/todayspun.pl"
* About to connect() to www.punoftheday.com port 80 (#0)
*   Trying 72.34.56.190...
* connected
* Connected to www.punoftheday.com (72.34.56.190) port 80 (#0)
> GET /cgi-bin/todayspun.pl HTTP/1.1
> User-Agent: curl/7.26.0
> Host: www.punoftheday.com
> Accept: */*
>
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Server: nginx/1.7.5
< Date: Sun, 14 Feb 2016 17:21:03 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Frame-Options: SAMEORIGIN
<
e3
document.write('&quot;The scientist had trouble reducing the liquid, he just couldn&rsquo;t concentrate.&quot;<br />')
document.write('<i>&copy; 1996-2011 <a href="http://www.punoftheday.com">Pun of the Day.com</a></i><br />')

0

* Connection #0 to host www.punoftheday.com left intact
* Closing connection #0

curl version is

$ curl -V
curl 7.26.0 (x86_64-pc-linux-gnu) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP

[titsuki]

It think that the curl command with "--raw" option can't detect cause of this failure. So, I added @recv_log.perl.say; line in "t/160-issue-67.t " file.

my $resp = HTTP::UserAgent.new.get(
    'http://www.punoftheday.com/cgi-bin/todayspun.pl'
);

IO::Socket::INET.^find_method('recv').unwrap($wrapped);
@recv_log.perl.say;

is(@recv_log.elems, 1, 'recv calls');
like($resp.content, rx/^^document.*'\')'$$/, 'resp' );

The result is

[{:args(\(:bin)), :ret(Buf[uint8].new(72, 84, 84, 80, 47, 49, 46, 49, 32, 50, 48, 48, 32, 79, 75, 13, 10, 83, 101, 114, 118, 101, 114, 58, 32, 110, 103, 105, 110, 120, 47, 49, 46, 55, 46, 53, 13, 10, 68, 97, 116, 101, 58, 32, 84, 117, 101, 44, 32, 49, 54, 32, 70, 101, 98, 32, 50, 48, 49, 54, 32, 49, 54, 58, 51, 54, 58, 49, 51, 32, 71, 77, 84, 13, 10, 67, 111, 110, 116, 101, 110, 116, 45, 84, 121, 112, 101, 58, 32, 116, 101, 120, 116, 47, 104, 116, 109, 108, 13, 10, 84, 114, 97, 110, 115, 102, 101, 114, 45, 69, 110, 99, 111, 100, 105, 110, 103, 58, 32, 99, 104, 117, 110, 107, 101, 100, 13, 10, 67, 111, 110, 110, 101, 99, 116, 105, 111, 110, 58, 32, 99, 108, 111, 115, 101, 13, 10, 88, 45, 70, 114, 97, 109, 101, 45, 79, 112, 116, 105, 111, 110, 115, 58, 32, 83, 65, 77, 69, 79, 82, 73, 71, 73, 78, 13, 10, 13, 10))}, {:args(\(1, :bin)), :ret(Buf[uint8].new(98))}, {:args(\(1, :bin)), :ret(Buf[uint8].new(56))}, {:args(\(1, :bin)), :ret(Buf[uint8].new(13))}, {:args(\(1, :bin)), :ret(Buf[uint8].new(10))}, {:args(\(186, :bin)), :ret(Buf[uint8].new(100, 111, 99, 117, 109, 101, 110, 116, 46, 119, 114, 105, 116, 101, 40, 39, 38, 113, 117, 111, 116, 59, 84, 104, 101, 32, 112, 117, 110, 99, 116, 117, 97, 108, 32, 122, 111, 109, 98, 105, 101, 32, 119, 97, 115, 32, 117, 110, 100, 101, 97, 100, 32, 111, 110, 32, 116, 105, 109, 101, 46, 38, 113, 117, 111, 116, 59, 60, 98, 114, 32, 47, 62, 39, 41, 10, 100, 111, 99, 117, 109, 101, 110, 116, 46, 119, 114, 105, 116, 101, 40, 39, 60, 105, 62, 38, 99, 111, 112, 121, 59, 32, 49, 57, 57, 54, 45, 50, 48, 49, 49, 32, 60, 97, 32, 104, 114, 101, 102, 61, 34, 104, 116, 116, 112, 58, 47, 47, 119, 119, 119, 46, 112, 117, 110, 111, 102, 116, 104, 101, 100, 97, 121, 46, 99, 111, 109, 34, 62, 80, 117, 110, 32, 111, 102, 32, 116, 104, 101, 32, 68, 97, 121, 46, 99, 111, 109, 60, 47, 97, 62, 60, 47, 105, 62, 60, 98, 114, 32, 47, 62, 39, 41, 10, 13, 10))}, {:args(\(1, :bin)), :ret(Buf[uint8].new(48))}, {:args(\(1, :bin)), :ret(Buf[uint8].new(13))}, {:args(\(1, :bin)), :ret(Buf[uint8].new(10))}]

But sorry I don't have any idea to solve this failure.

[jonathanstowe]

I have actually seen this one now, it was on a work network with a transparent proxy. The problem is really with the test rather than the code itself. I'll think of a way round this.