Skip Menu |

This queue is for tickets about the XML-Compile CPAN distribution.

Report information
The Basics
Id: 108410
Status: resolved
Priority: 0/
Queue: XML-Compile
People
Owner: Nobody in particular
Requestors: mjgardner [...] cpan.org
Cc: peter.sandin [...] ziprecruiter.com
AdminCc:
Bug Information
Severity: Important
Broken in: 1.50
Fixed in: 1.51
Attachments
signature.asc

History Show all quoted text
  Tue Nov 03 12:46:36 2015 mjgardner [...] cpan.org - Ticket created
CC: peter.sandin [...] ziprecruiter.com
Subject: base64Binary content becomes undef if it contains wide characters
I'm calling the service at https://webservices.netsuite.com/wsdl/v2015_1_0/netsuite.wsdl with XML::Compile::WSDL11. When attempting to send string content in a base64Binary element, I get errors like the following when the string contains wide characters: error: illegal value `undef' for type {http://www.w3.org/2001/XMLSchema}base64Binary at platformMsgs:upsert/record/mediaItemList/mediaItem/content Normally the MIME::Base64 encode_base64 function used by XML::Compile::Schema::BuiltInTypes's base64Binary support would croak on receiving wide characters on content without an encoding. However the calls to encode_base64 and decode_base64 in XML::Compile::Schema::BuiltInTypes (starting in line 306 in v1.50) are wrapped in eval calls, so the croak is neutered and the passed string becomes undef. The croaked error should instead be caught and passed as the correct error string, rather than the confusing message above. This would hint to the developer that they need to make sure their string has been encoded so that MIME::Base64 can correctly encode it to base64.
  Tue Nov 03 13:45:22 2015 ether [...] cpan.org - Broken in 0.01 deleted
  Tue Nov 03 13:45:23 2015 ether [...] cpan.org - Broken in 0.02 deleted
  Tue Nov 03 13:45:24 2015 ether [...] cpan.org - Broken in 0.04 deleted
  Tue Nov 03 13:45:24 2015 ether [...] cpan.org - Broken in 0.05 deleted
  Tue Nov 03 13:45:25 2015 ether [...] cpan.org - Broken in 0.07 deleted
  Tue Nov 03 13:45:25 2015 ether [...] cpan.org - Broken in 0.08 deleted
  Tue Nov 03 13:45:26 2015 ether [...] cpan.org - Broken in 0.11 deleted
  Tue Nov 03 13:45:27 2015 ether [...] cpan.org - Broken in 0.12 deleted
  Tue Nov 03 13:45:27 2015 ether [...] cpan.org - Broken in 0.15 deleted
  Tue Nov 03 13:45:28 2015 ether [...] cpan.org - Broken in 0.16 deleted
  Tue Nov 03 13:45:30 2015 ether [...] cpan.org - Broken in 0.17 deleted
  Tue Nov 03 13:45:31 2015 ether [...] cpan.org - Broken in 0.18 deleted
  Tue Nov 03 13:45:31 2015 ether [...] cpan.org - Broken in 0.5 deleted
  Tue Nov 03 13:45:32 2015 ether [...] cpan.org - Broken in 0.51 deleted
  Tue Nov 03 13:45:32 2015 ether [...] cpan.org - Broken in 0.52 deleted
  Tue Nov 03 13:45:33 2015 ether [...] cpan.org - Broken in 0.53 deleted
  Tue Nov 03 13:45:33 2015 ether [...] cpan.org - Broken in 0.54 deleted
  Tue Nov 03 13:45:34 2015 ether [...] cpan.org - Broken in 0.55 deleted
  Tue Nov 03 13:45:34 2015 ether [...] cpan.org - Broken in 0.56 deleted
  Tue Nov 03 13:45:35 2015 ether [...] cpan.org - Broken in 0.57 deleted
  Tue Nov 03 13:45:35 2015 ether [...] cpan.org - Broken in 0.58 deleted
  Tue Nov 03 13:45:36 2015 ether [...] cpan.org - Broken in 0.59 deleted
  Tue Nov 03 13:45:37 2015 ether [...] cpan.org - Broken in 0.60 deleted
  Tue Nov 03 13:45:37 2015 ether [...] cpan.org - Broken in 0.63 deleted
  Tue Nov 03 13:45:38 2015 ether [...] cpan.org - Broken in 0.64 deleted
  Tue Nov 03 13:45:39 2015 ether [...] cpan.org - Broken in 0.65 deleted
  Tue Nov 03 13:45:41 2015 ether [...] cpan.org - Broken in 0.66 deleted
  Tue Nov 03 13:45:43 2015 ether [...] cpan.org - Broken in 0.67 deleted
  Tue Nov 03 13:45:45 2015 ether [...] cpan.org - Broken in 0.68 deleted
  Tue Nov 03 13:45:46 2015 ether [...] cpan.org - Broken in 0.69 deleted
  Tue Nov 03 13:45:47 2015 ether [...] cpan.org - Broken in 0.70 deleted
  Tue Nov 03 13:45:47 2015 ether [...] cpan.org - Broken in 0.71 deleted
  Tue Nov 03 13:45:48 2015 ether [...] cpan.org - Broken in 0.72 deleted
  Tue Nov 03 13:45:48 2015 ether [...] cpan.org - Broken in 0.73 deleted
  Tue Nov 03 13:45:49 2015 ether [...] cpan.org - Broken in 0.74 deleted
  Tue Nov 03 13:45:50 2015 ether [...] cpan.org - Broken in 0.75 deleted
  Tue Nov 03 13:45:50 2015 ether [...] cpan.org - Broken in 0.76 deleted
  Tue Nov 03 13:45:51 2015 ether [...] cpan.org - Broken in 0.77 deleted
  Tue Nov 03 13:45:52 2015 ether [...] cpan.org - Broken in 0.78 deleted
  Tue Nov 03 13:45:52 2015 ether [...] cpan.org - Broken in 0.79 deleted
  Tue Nov 03 13:45:52 2015 ether [...] cpan.org - Broken in 0.80 deleted
  Tue Nov 03 13:45:53 2015 ether [...] cpan.org - Broken in 0.81 deleted
  Tue Nov 03 13:45:53 2015 ether [...] cpan.org - Broken in 0.82 deleted
  Tue Nov 03 13:45:54 2015 ether [...] cpan.org - Broken in 0.83 deleted
  Tue Nov 03 13:45:54 2015 ether [...] cpan.org - Broken in 0.84 deleted
  Tue Nov 03 13:45:55 2015 ether [...] cpan.org - Broken in 0.85 deleted
  Tue Nov 03 13:45:57 2015 ether [...] cpan.org - Broken in 0.86 deleted
  Tue Nov 03 13:45:58 2015 ether [...] cpan.org - Broken in 0.87 deleted
  Tue Nov 03 13:45:59 2015 ether [...] cpan.org - Broken in 0.88 deleted
  Tue Nov 03 13:46:01 2015 ether [...] cpan.org - Broken in 0.89 deleted
  Tue Nov 03 13:46:01 2015 ether [...] cpan.org - Broken in 0.90 deleted
  Tue Nov 03 13:46:02 2015 ether [...] cpan.org - Broken in 0.91 deleted
  Tue Nov 03 13:46:02 2015 ether [...] cpan.org - Broken in 0.92 deleted
  Tue Nov 03 13:46:03 2015 ether [...] cpan.org - Broken in 0.93 deleted
  Tue Nov 03 13:46:03 2015 ether [...] cpan.org - Broken in 0.93-raw deleted
  Tue Nov 03 13:46:04 2015 ether [...] cpan.org - Broken in 0.94 deleted
  Tue Nov 03 13:46:04 2015 ether [...] cpan.org - Broken in 0.95 deleted
  Tue Nov 03 13:46:05 2015 ether [...] cpan.org - Broken in 0.96 deleted
  Tue Nov 03 13:46:06 2015 ether [...] cpan.org - Broken in 0.97 deleted
  Tue Nov 03 13:46:07 2015 ether [...] cpan.org - Broken in 0.98 deleted
  Tue Nov 03 13:46:07 2015 ether [...] cpan.org - Broken in 0.99 deleted
  Tue Nov 03 13:46:08 2015 ether [...] cpan.org - Broken in 1.00 deleted
  Tue Nov 03 13:46:10 2015 ether [...] cpan.org - Broken in 1.01 deleted
  Tue Nov 03 13:46:12 2015 ether [...] cpan.org - Broken in 1.02 deleted
  Tue Nov 03 13:46:13 2015 ether [...] cpan.org - Broken in 1.03 deleted
  Tue Nov 03 13:46:13 2015 ether [...] cpan.org - Broken in 1.04 deleted
  Tue Nov 03 13:46:14 2015 ether [...] cpan.org - Broken in 1.05 deleted
  Tue Nov 03 13:46:15 2015 ether [...] cpan.org - Broken in 1.06 deleted
  Tue Nov 03 13:46:16 2015 ether [...] cpan.org - Broken in 1.07 deleted
  Tue Nov 03 13:46:16 2015 ether [...] cpan.org - Broken in 1.08 deleted
  Tue Nov 03 13:46:17 2015 ether [...] cpan.org - Broken in 1.09 deleted
  Tue Nov 03 13:46:17 2015 ether [...] cpan.org - Broken in 1.10 deleted
  Tue Nov 03 13:46:19 2015 ether [...] cpan.org - Broken in 1.11 deleted
  Tue Nov 03 13:46:20 2015 ether [...] cpan.org - Broken in 1.12 deleted
  Tue Nov 03 13:46:21 2015 ether [...] cpan.org - Broken in 1.13 deleted
  Tue Nov 03 13:46:21 2015 ether [...] cpan.org - Broken in 1.14 deleted
  Tue Nov 03 13:46:22 2015 ether [...] cpan.org - Broken in 1.15 deleted
  Tue Nov 03 13:46:24 2015 ether [...] cpan.org - Broken in 1.16 deleted
  Tue Nov 03 13:46:25 2015 ether [...] cpan.org - Broken in 1.17 deleted
  Tue Nov 03 13:46:26 2015 ether [...] cpan.org - Broken in 1.18 deleted
  Tue Nov 03 13:46:26 2015 ether [...] cpan.org - Broken in 1.19 deleted
  Tue Nov 03 13:46:26 2015 ether [...] cpan.org - Broken in 1.20 deleted
  Tue Nov 03 13:46:27 2015 ether [...] cpan.org - Broken in 1.21 deleted
  Tue Nov 03 13:46:27 2015 ether [...] cpan.org - Broken in 1.22 deleted
  Tue Nov 03 13:46:28 2015 ether [...] cpan.org - Broken in 1.23 deleted
  Tue Nov 03 13:46:28 2015 ether [...] cpan.org - Broken in 1.24 deleted
  Tue Nov 03 13:46:29 2015 ether [...] cpan.org - Broken in 1.25 deleted
  Tue Nov 03 13:46:30 2015 ether [...] cpan.org - Broken in 1.26 deleted
  Tue Nov 03 13:46:30 2015 ether [...] cpan.org - Broken in 1.27 deleted
  Tue Nov 03 13:46:30 2015 ether [...] cpan.org - Broken in 1.28 deleted
  Tue Nov 03 13:46:31 2015 ether [...] cpan.org - Broken in 1.29 deleted
  Tue Nov 03 13:46:31 2015 ether [...] cpan.org - Broken in 1.30 deleted
  Tue Nov 03 13:46:32 2015 ether [...] cpan.org - Broken in 1.31 deleted
  Tue Nov 03 13:46:33 2015 ether [...] cpan.org - Broken in 1.32 deleted
  Tue Nov 03 13:46:33 2015 ether [...] cpan.org - Broken in 1.33 deleted
  Tue Nov 03 13:46:34 2015 ether [...] cpan.org - Broken in 1.34 deleted
  Tue Nov 03 13:46:34 2015 ether [...] cpan.org - Broken in 1.35 deleted
  Tue Nov 03 13:46:34 2015 ether [...] cpan.org - Broken in 1.36 deleted
  Tue Nov 03 13:46:35 2015 ether [...] cpan.org - Broken in 1.37 deleted
  Tue Nov 03 13:46:36 2015 ether [...] cpan.org - Broken in 1.38 deleted
  Tue Nov 03 13:46:37 2015 ether [...] cpan.org - Broken in 1.39 deleted
  Tue Nov 03 13:46:39 2015 ether [...] cpan.org - Broken in 1.40 deleted
  Tue Nov 03 13:46:40 2015 ether [...] cpan.org - Broken in 1.41 deleted
  Tue Nov 03 13:46:40 2015 ether [...] cpan.org - Broken in 1.41-raw deleted
  Tue Nov 03 13:46:41 2015 ether [...] cpan.org - Broken in 1.42 deleted
  Tue Nov 03 13:46:41 2015 ether [...] cpan.org - Broken in 1.43 deleted
  Tue Nov 03 13:46:41 2015 ether [...] cpan.org - Broken in 1.44 deleted
  Tue Nov 03 13:46:42 2015 ether [...] cpan.org - Broken in 1.45 deleted
  Tue Nov 03 13:46:42 2015 ether [...] cpan.org - Broken in 1.46 deleted
  Tue Nov 03 13:46:43 2015 ether [...] cpan.org - Broken in 1.47 deleted
  Tue Nov 03 13:46:44 2015 ether [...] cpan.org - Broken in 1.48 deleted
  Tue Nov 03 13:46:44 2015 ether [...] cpan.org - Broken in 1.49 deleted
  Wed Nov 04 03:21:34 2015 solutions [...] overmeer.net - Correspondence added
Subject: Re: [rt.cpan.org #108410] base64Binary content becomes undef if it contains wide characters
Date: Wed, 4 Nov 2015 09:21:18 +0100
To: Mark Gardner via RT <bug-XML-Compile [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
* Mark Gardner via RT (bug-XML-Compile@rt.cpan.org) [151103 17:46]: Show quoted text
> Tue Nov 03 12:46:36 2015: Request 108410 was acted upon. > Transaction: Ticket created by MJGARDNER > Queue: XML-Compile > Subject: base64Binary content becomes undef if it contains wide characters > > The croaked error should instead be caught and passed as the correct > error string, rather than the confusing message above. This would hint to > the developer that they need to make sure their string has been encoded > so that MIME::Base64 can correctly encode it to base64.
I agree. As second problem: you want to see the error, to get a hint about wide-characters. XML::Compile tries to hide as much as possible of the XML to the user of the module. Do we really want the user to understand that it is a base64 field, not just a string? So: wouldn't it be better to always call "utf8::downgrade" on the parameter? I think that base64 encoded fields are to be considered raw byte fields, not text string fields. So wide characters are accidents of Perl upgrading them, for instance in a regular expression. What do you think about this? -- greetz, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
  Wed Nov 04 03:21:34 2015 The RT System itself - Status changed from 'new' to 'open'
  Wed Nov 04 08:45:26 2015 mjgardner [...] cpan.org - Correspondence added
Agreed, just make sure to give the error if utf8::downgrade() fails and dies per the docs.
  Thu Nov 05 03:20:12 2015 solutions [...] overmeer.net - Correspondence added
Subject: Re: [rt.cpan.org #108410] base64Binary content becomes undef if it contains wide characters
Date: Thu, 5 Nov 2015 09:19:45 +0100
To: Mark Gardner via RT <bug-XML-Compile [...] rt.cpan.org>
From: Mark Overmeer <solutions [...] overmeer.net>
* Mark Gardner via RT (bug-XML-Compile@rt.cpan.org) [151104 13:45]: Show quoted text
> Queue: XML-Compile > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=108410 > > > Agreed, just make sure to give the error if utf8::downgrade() fails > and dies per the docs.
I have changed the format code into: $builtin_types{base64Binary} = { parse => sub { eval { decode_base64 $_[0] } } , format => sub { my $a = $_[0]; eval { utf8::downgrade($a) }; if($@) { error __x"use Encode::encode() for base64Binary field at {path}" , path => $_[2]; } encode_base64 $a, ''; } ... The regression-test script output on a wide character now says: use Encode::encode() for base64Binary field at {http://test-types}test6 So: it does not tell the error, but focusses on the solution. What do you think? -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
  Thu Nov 05 11:47:20 2015 mjg [...] phoenixtrap.com - Correspondence added
CC: Mark Joseph Gardner <mjgardner [...] cpan.org>, Peter Sandin <peter.sandin [...] ziprecruiter.com>
Subject: Re: [rt.cpan.org #108410] base64Binary content becomes undef if it contains wide characters
Date: Thu, 5 Nov 2015 11:47:03 -0500
To: Mark Overmeer via RT <bug-XML-Compile [...] rt.cpan.org>
From: Mark Gardner <mjg [...] phoenixtrap.com>
That looks OK. Can you provide a patch or dev release for me to test? Show quoted text
> On Nov 5, 2015, at 3:20 AM, Mark Overmeer via RT <bug-XML-Compile@rt.cpan.org> wrote: > > <URL: https://rt.cpan.org/Ticket/Display.html?id=108410 > > > * Mark Gardner via RT (bug-XML-Compile@rt.cpan.org) [151104 13:45]:
>> Queue: XML-Compile >> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=108410 > >> >> Agreed, just make sure to give the error if utf8::downgrade() fails >> and dies per the docs.
> > I have changed the format code into: > > $builtin_types{base64Binary} = > { parse => sub { eval { decode_base64 $_[0] } } > , format => sub { > my $a = $_[0]; > eval { utf8::downgrade($a) }; > if($@) > { error __x"use Encode::encode() for base64Binary field at {path}" > , path => $_[2]; > } > encode_base64 $a, ''; > } > ... > > The regression-test script output on a wide character now says: > > use Encode::encode() for base64Binary field at {http://test-types}test6 > > So: it does not tell the error, but focusses on the solution. > What do you think? > -- > Regards, > MarkOv > > ------------------------------------------------------------------------ > Mark Overmeer MSc MARKOV Solutions > Mark@Overmeer.net solutions@overmeer.net > http://Mark.Overmeer.net http://solutions.overmeer.net > >
Download signature.asc
application/pgp-signature 527b

Message body not shown because it is not plain text.

  Thu Nov 05 11:52:24 2015 Mark [...] Overmeer.net - Correspondence added
Subject: Re: [rt.cpan.org #108410] base64Binary content becomes undef if it contains wide characters
Date: Thu, 5 Nov 2015 17:52:11 +0100
To: "mjg [...] phoenixtrap.com via RT" <bug-XML-Compile [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* mjg@phoenixtrap.com via RT (bug-XML-Compile@rt.cpan.org) [151105 16:47]: Show quoted text
> Queue: XML-Compile > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=108410 > > > That looks OK. Can you provide a patch or dev release for me to test?
I have now released it as XML::Compile v1.51 to CPAN. -- success, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
  Fri Mar 11 08:50:05 2016 MARKOV [...] cpan.org - Correspondence added
Fixed some time ago
  Fri Mar 11 08:50:08 2016 MARKOV [...] cpan.org - Status changed from 'open' to 'resolved'
  Fri Mar 11 08:50:10 2016 MARKOV [...] cpan.org - Fixed in 1.51 added