Skip Menu |

This queue is for tickets about the SOAP-Lite CPAN distribution.

Report information
The Basics
Id: 107924
Status: open
Priority: 0/
Queue: SOAP-Lite

People
Owner: Nobody in particular
Requestors: Steffen_Ullrich [...] genua.de
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Interaction with LWP broken regarding ssl_opts
If on is using ssl_opts like this: SOAP::Lite->proxy( 'https://...', ssl_opts => { SSL_ca_file => ... }) It will not set the given SSL options as one would expect. The reason is that SOAP::Transport::HTTP::Client::new will check for all arguments if there is a function with this name in LWP::UserAgent and in this case not give the arguments to new but to the functions. This means it will do the following $ua = LWP::UserAgent->new(...) # no ssl_opts $ua->ssl_opts({ SSL_ca_file => ... }) The last call will not set the ssl_opts in LWP::UserAgent but instead will treat the only argument as a string (i.e. "HASH(0x....")) and return the stored SSL option with this name. Giving instead ssl_opts as array ref works because in this case the array will be expanded when calling which will result in $ua->ssl_opts( SSL_ca_file => ... ) Note that the documentation explicitly states with an example that the ssl_opts should be given as a hash. Regards, Steffen
Subject: Re: [rt.cpan.org #107924] Interaction with LWP broken regarding ssl_opts
Date: Fri, 23 Oct 2015 19:52:25 -0700
To: bug-SOAP-Lite [...] rt.cpan.org
From: Fred Moyer <fred [...] redhotpenguin.com>
If you have a patch, I'd love a pull request at https://github.com/redhotpenguin/soaplite On Thu, Oct 22, 2015 at 9:22 AM, Steffen Ullrich via RT <bug-SOAP-Lite@rt.cpan.org> wrote: Show quoted text
> Thu Oct 22 12:22:53 2015: Request 107924 was acted upon. > Transaction: Ticket created by SULLR > Queue: SOAP-Lite > Subject: Interaction with LWP broken regarding ssl_opts > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: Steffen_Ullrich@genua.de > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=107924 > > > > If on is using ssl_opts like this: > > SOAP::Lite->proxy( 'https://...', ssl_opts => { SSL_ca_file => ... }) > > It will not set the given SSL options as one would expect. > > The reason is that SOAP::Transport::HTTP::Client::new will check for all arguments if there is a function with this name in LWP::UserAgent and in this case not give the arguments to new but to the functions. This means it will do the following > > $ua = LWP::UserAgent->new(...) # no ssl_opts > $ua->ssl_opts({ SSL_ca_file => ... }) > > The last call will not set the ssl_opts in LWP::UserAgent but instead will treat the only argument as a string (i.e. "HASH(0x....")) and return the stored SSL option with this name. > > Giving instead ssl_opts as array ref works because in this case the array will > be expanded when calling which will result in > > $ua->ssl_opts( SSL_ca_file => ... ) > > Note that the documentation explicitly states with an example that the ssl_opts > should be given as a hash. > > Regards, > Steffen
Subject: Re: [rt.cpan.org #107924] Interaction with LWP broken regarding ssl_opts
Date: Sun, 25 Oct 2015 12:29:01 +0100
To: "fred [...] redhotpenguin.com via RT" <bug-SOAP-Lite [...] rt.cpan.org>
From: Steffen Ullrich <Steffen_Ullrich [...] genua.de>
On Fri, Oct 23, 2015 at 10:53:33PM -0400, "fred@redhotpenguin.com via RT" <bug-SOAP-Lite@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=107924 > > > If you have a patch, I'd love a pull request at > https://github.com/redhotpenguin/soaplite
Unfortunately it is not that clear how exactly this should be fixed, because there are several ways, like: - Update the documentation to make clear that ssl_opts should be an array, contrary to what the documentation currently says. This will not break any existing code, because it does not change how SOAP::Lite behaves. - Handle ssl_opts in a special way in SOAP::Lite, so that using a hash for ssl_opts works. To not break existing code one should handle the case with ssl_opts as an array like before. - Don't touch SOAP::Lite at all but instead change LWP::UserAgent::ssl_opts. Currently it assumes that if only a single argument is given this must be the key to the internal ssl_opts hash. But using a reference as a key makes no sense so one could add support for using a hash reference as an argument for ssl_opts without breaking existing code. I would actually favor the last option, because this way the method ssl_opts could also be used consistently to the attribute ssl_opts and not silently do nothing like it does now. Regards, Steffen
On Sun Oct 25 11:29:24 2015, SULLR wrote: Show quoted text
> On Fri, Oct 23, 2015 at 10:53:33PM -0400, "fred@redhotpenguin.com via > RT" <bug-SOAP-Lite@rt.cpan.org> wrote:
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=107924 > > > > > If you have a patch, I'd love a pull request at > > https://github.com/redhotpenguin/soaplite
> > Unfortunately it is not that clear how exactly this should be fixed, > because > there are several ways, like: > > - Update the documentation to make clear that ssl_opts should be an > array, > contrary to what the documentation currently says. This will not > break any > existing code, because it does not change how SOAP::Lite behaves. > - Handle ssl_opts in a special way in SOAP::Lite, so that using a hash > for > ssl_opts works. To not break existing code one should handle the > case with > ssl_opts as an array like before. > - Don't touch SOAP::Lite at all but instead change > LWP::UserAgent::ssl_opts. > Currently it assumes that if only a single argument is given this > must be > the key to the internal ssl_opts hash. But using a reference as a > key > makes no sense so one could add support for using a hash reference > as an > argument for ssl_opts without breaking existing code. > > I would actually favor the last option, because this way the method > ssl_opts > could also be used consistently to the attribute ssl_opts and not > silently > do nothing like it does now. > > Regards, > Steffen
The second of these approaches has been implemented in the repository. See https://github.com/redhotpenguin/soaplite/pull/27 for details of the PR.