libwww-perl / HTTP-Message

The HTTP-Message distribution contains classes useful for representing the messages passed in HTTP style communication.

Home Page:https://metacpan.org/pod/HTTP::Message

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Locale-specific (?) test failures (6.19-TRIAL)

eserte opened this issue · comments

t/response.t fails on some of my smokers:

Caught error while processing RFC 2047 'filename' parameter: Unknown encoding 'NOT-A-CHARSET' at /home/cpansand/.cpan/build/2019011619/HTTP-Message-6.19-XOqann/blib/lib/HTTP/Response.pm line 175.
    
    #   Failed test 'attwithisofn2231iso: Attachment with ISO-8859-1 charset'
    #   at t/response.t line 201.
    #          got: 'foo-?.html'
    #     expected: 'foo-<E4>.html'
    
    #   Failed test 'attwithfn2231utf8: Attachment with UTF-8 charset'
    #   at t/response.t line 208.
Wide character in print at /usr/perl5.20.1Dp/lib/site_perl/5.20.1/Test/Builder.pm line 1826.
    #          got: 'foo-?-?.html'
    #     expected: 'foo-ä-€.html'
    
    #   Failed test 'attfnboth: Attachment with both "filename" parameter and "filename*" parameter. The "filename*" parameter is preferred.'
    #   at t/response.t line 217.
    #          got: 'foo-?.html'
    #     expected: 'foo-<E4>.html'
    
    #   Failed test 'attfnboth2: Attachment with both parameters, but swapped order. The "filename*" parameter is still preferred.'
    #   at t/response.t line 225.
    #          got: 'foo-?.html'
    #     expected: 'foo-<E4>.html'
    # Looks like you failed 4 tests of 4.

#   Failed test 'RFC 8187: tests from Content-Disposition test suite'
#   at t/response.t line 230.
# Looks like you failed 1 test of 69.
t/response.t ................ 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/69 subtests 

It seems that this can be reproduced by setting LC_ALL=C.

Thanks for this @eserte. Looks like this was probably introduced in 01fd455 @zmughal any thoughts on this?

Just an idea: the tests use "ä" but the C locale means US-ASCII encoding+charset, which does not contain this character, so it's lost through the conversions.

(Another problem is the usage of "locale_fs" at all --- the current locale setting does not say anything about the encoding of filenames. But unfortunately Unix does not have anything better)

@zmughal do you have a moment to look into fixing this? I'd like to get a release out and this is holding it up. The alternative would be to back out of these changes for now and try them again at a later date.

Thanks @daxim! Could you create a pull request so that we can get the Travis tests running on this change?