bliako has asked for the wisdom of the Perl Monks concerning the following question:

Esteem Monks,

LWP::ConsoleLogger::Easy installs some hooks on LWP::UserAgent for printing headers, content etc. during an LWP transaction.

For a particular website the console is messed up after LWP::ConsoleLogger::Easy prints received JSON response containing turkish characters. I suspect it contains broken unicode or I am sending the wrong headers. For other websites with greek or turkish characters in html it works fine. My question is whether I can do something about it.

use strict;
use warnings;

use LWP::UserAgent;
use LWP::ConsoleLogger::Easy qw/debug_ua/;

# with this uncommented, it still breaks but differently
#binmode STDERR, ':utf8';

my $url = 'https://geocode.arcgis.com/arcgis/rest/services/World/Geoco
+deServer/suggest?f=json&maxSuggestions=6&outSR=%7B%22latestWkid%22:43
+26%7D&text=kayseri';
#my $url = 'https://www.sigmalive.com';
#my $url = 'https://www.havadiskibris.com/';

# this also breaks:
# use utf8;
# my $url = 'https://geocode.arcgis.com/arcgis/rest/services/World/Geo
+codeServer/suggest?f=json&maxSuggestions=6&outSR=%7B%22latestWkid%22:
+4326%7D&text=αθήνα';

my $req = HTTP::Request->new(
    'GET' => $url,
    [
        'Connection' => 'keep-alive',
        'Accept' => '*/*',
        'Accept-Encoding' => 'gzip, deflate, br',
        'Accept-Language' => 'en-GB,en;q=0.5',
        'Referer' => 'https://livingatlas.arcgis.com/',
        'Content-Type' => 'application/json',
#        'Content-Type' => 'text/html; charset=utf-8',
        'User-Agent' => 'Mozilla/5.0 (Macintosh; Intel Mac OS X 13.5; 
+rv:116.0) Gecko/20100101 Firefox/116.0',
        'Origin' => 'https://livingatlas.arcgis.com',
        'Sec-Fetch-Dest' => 'empty',
        'Sec-Fetch-Mode' => 'cors',
        'Sec-Fetch-Site' => 'same-site'
    ],
);
my $ua = LWP::UserAgent->new();
my $logger = debug_ua($ua);
my $response = $ua->request($req);

#print $response->decoded_content;

# the console is messed, this is not printed:
print "\n\ndone\n\n";
# echo $? prints 5, so this is reached:
exit(5);

[download]

many thanks, bliako

  • Comment on LWP::ConsoleLogger::Easy messes the console on (seemingly) unicode LWP response: is it a case of broken unicode?
  • Download Code

Replies are listed 'Best First'.
Re: LWP::ConsoleLogger::Easy messes the console on (seemingly) unicode LWP response: is it a case of broken unicode?
by cavac (Prior) on Aug 24, 2023 at 15:02 UTC

    For any text in headers, you are best of with sticking to ISO-8859-1. For content, you have to mark that as UTF-8. Most likely, you want:

    Content-Type: application/json; charset=utf-8

    Depending on the content type, that charset may or may not also be marked within the content by the unicode mark at the beginning of the "file".

    If the charset is not specified, most useragents will assume ISO-8859-1, according to HTTP spec. But some may infer other charsets, depending on things like the language header. Important here to note is that, while your request can specify any header you like, the server isn't really obligated to adhere to most of them. And the client will usually ignore all the headers you sent to the server and will only work on the headers that the server has sent back to you in the response.

    For example, you set a 'Content-Type' request header. This is NOT a valid header. (Well, technically, it is valid HTTP, but it is ignored by servers because it's not in the spec as a client request header). The Content-Type header is a response header only, unless i seriously misremember the RFCs. The content type is set by the server and there is no in-header way to specify the charset the client wants.

    For JSON, your best bet would probably to shove it through the JSON decoder library of your choice, hope it gets decoded correctly and then put it into your logger.

    I haven't player with LWP::ConsoleLogger::*, but best bet is that it gets confused by a missing charset=utf-8 declaration or something. Most JSON modules on CPAN on the other hand make the mostly sensible choice of assuming that everything is UTF-8, because that's the same assumption JavaScript in most modern browsers would also make.

    PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
[reply]
[d/l]
[select]
[reply]
      For example, you set a 'Content-Type' request header. This is NOT a valid header.

      I was throwing at it all I could find

      JSON::XS did not have any problem decode_json'ing that JSON. And if I don't import and use the Logger print $response->decoded_content; works just fine (without binmode'ing STDOUT). Additionally, sometimes it fails (=messing the console) while printing Content and sometimes when it prints Text (which I believe is printing decoded JSON)

      I will follow what Corion said and report it. Though I hate dumping encoding bugs on unsuspected passerbys.

      thanks!

[reply]
[d/l]
[select]

        Though I hate dumping encoding bugs on unsuspected passerbys.

        Wish i had the same luxury. It feels like i'm spending half my life fixing encoding bugs these days. Unicode is great... when it works. Just last month i spend half an afternoon trying to fix a printing bug, until i realized that font i was using had a bug...

        But look at it this way: Humans have lots of different cultures and writing systems. The more Unicode bugs we fix, the more inclusive our programs become. In the long term, tearing down the walls that divide cultures will (hopefully) bring people closer together and reduce the prevalence of bigotry and wars.

        PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
[reply]
        I could be wrong, but I think the only thing that would corrupt a terminal would be control codes, and specifically the escape character \e. Any utility meant to dump protocol traffic to a terminal should always escape the control codes. Before reporting it, see if you can find the line that does the printing, and add this: 
        $str =~ /([\0-\x09\x0B\x1F])/sprintf("\\x%02X", ord $1)/ge;

        [download]
        and see if it stops corrupting your terminal. Then you could submit a pull request instead of a bug report :-)
[reply]
[d/l]

Back to Seekers of Perl Wisdom