Bug 460716 - Use lwp-request HTTPS to connect to a non-existent, non routable host, using a -t timeout value ignores the time out.
Summary: Use lwp-request HTTPS to connect to a non-existent, non routable host, using ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: perl-libwww-perl
Version: 5.2
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Petr Šabata
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 743405 807971
TreeView+ depends on / blocked
 
Reported: 2008-08-30 03:05 UTC by Michael Kearey
Modified: 2018-11-14 17:17 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-02 15:31:57 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
CPAN 3316 0 None None None Never
CPAN 22839 0 None None None Never
Red Hat Bugzilla 750793 0 unspecified CLOSED LWP::UserAgent 'timeout' parameter does not work for HTTPS URLs 2021-02-22 00:41:40 UTC

Description Michael Kearey 2008-08-30 03:05:36 UTC
Description of problem:
Use lwp-request HTTPS to connect to a non-existent socket or host with -t timeout value, the time out is ignored.

Use lwp-request to connect a HTTP non-existent socket or host and the time out is honoured.

Additionally, use lwp-request to connect to host that has a non-HTTPS process listening on the default HTTPS socket the timeout _is_ honoured.

It seems that the initial socket connect for HTTPS is non-blocking. Once a socket is made and the SSL handshake is attempted _that_ part honours the timeout.

Version-Release number of selected component (if applicable):
$ rpm -qf `which lwp-request `
perl-libwww-perl-5.805-1.1.1


How reproducible:
100%

Steps to Reproduce:
1. Install perl-libwww-perl, perl-Crypt-SSLeay

2. Run command using a non-existent host/socket :
lwp-request -uxS -t 5 http://10.0.0.42/   


3. Wait for the initial socket connect to timeout.
  
Actual results:

Notice the time in 'real' of 3 minutes 9 seconds

$ time lwp-request -uxS -t 5 https://10.0.0.49
LWP::UserAgent::new: ()
LWP::UserAgent::request: ()
LWP::UserAgent::send_request: GET https://10.0.0.49
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::UserAgent::request: Simple response: Internal Server Error
GET https://10.0.0.49
GET https://10.0.0.49 --> 500 Connect failed: connect: Connection timed out; Connection timed out
500 Connect failed: connect: Connection timed out; Connection timed out

real    3m9.139s
user    0m0.118s
sys     0m0.023s 

Expected results:
We should timeout at about 5-6 seconds, not the default three or so minutes.


Additional info:

Expanding on my description, here I set a netcat socket listening on port 443, I see the timeout for SSL negotiation is honoured:

$ nc -l 443

$ time lwp-request -uxS -t 5 https://dogfood.bne.redhat.com
LWP::UserAgent::new: ()
LWP::UserAgent::request: ()
LWP::UserAgent::send_request: GET https://dogfood.bne.redhat.com
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::UserAgent::request: Simple response: Internal Server Error
GET https://dogfood.bne.redhat.com
GET https://dogfood.bne.redhat.com --> 500 SSL negotiation failed:
500 SSL negotiation failed:

real    0m6.177s
user    0m0.151s
sys     0m0.022s

If we attempt to connect to a non-existent socket the initial socket connect ignores the timeout.

To summarise, for non-HTTPS socket connects we honour the timeout. For SSL, the initial socket connect ignores the timeout, only the SSL negotiation phase honours it.


I have found the following :

http://markmail.org/message/g7w2fcuxtpdicuqs#query:lwp-request SSL timeout+page:1+mid:xzohato3vg3xjote+state:results


It suggested a workaround to have SSL connection timeout to work is to do the following :

Line 51 of /usr/lib/perl5/vendor_perl/5.8.8/LWP/Protocol/http.pm :

   # perl 5.005's IO::Socket does not have the blocking method.
   #eval { $sock->blocking(0); };    <---- Commented out by me



Line 53 of /usr/lib/perl5/vendor_perl/5.8.8/Net/HTTPS.pm:

# The underlying SSLeay classes fails to work if the socket is
# placed in non-blocking mode.  This override of the blocking
# method makes sure it stays the way it was created.
#sub blocking { }  # noop      <--- commented out


After making the changes the following tests show the timeout is working, BUT the messages are just ugly for SSL. 
$ lwp-request -uxS -t 5 https://10.0.0.49
LWP::UserAgent::new: ()
LWP::UserAgent::request: ()
LWP::UserAgent::send_request: GET https://10.0.0.49
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::UserAgent::request: Simple response: Internal Server Error
GET https://10.0.0.49
GET https://10.0.0.49 --> 500 Connect failed: connect: timeout; Bad file descriptor
500 Connect failed: connect: timeout; Bad file descriptor



Note that this is done using ONLY perl-libwww-perl, perl-Crypt-SSLeay , making sure that perl-IO-Socket-SSL is NOT installed.

Some time in the past it was determined that SSLeay classes could not work if the socket was set to blocking, and so any attempts to use it were disabled. Now it seems SSLLeay does handle it ok but there needs to be more work to handle the timeout message properly.

This problem exists in all perl releases I am aware of. I pulled down latest CPAN and it has the same behaviour. I don't know how this issue is to be fixed in the RHEL lifetime or if it ever will. Perhaps it can be raised upstream?

Comment 1 Michael Kearey 2008-08-30 03:07:03 UTC
Correction - For the 'Steps to Reproduce'


2. Run command using a non-existent host/socket :
lwp-request -uxS -t 5 https://10.0.0.42/

Comment 2 RHEL Program Management 2009-03-26 17:18:23 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 10 Petr Pisar 2011-10-24 14:57:59 UTC
This long standing bug is tracked by upstream since year 2006 without success: <https://rt.cpan.org/Public/Bug/Display.html?id=22839>.

Comment 11 Petr Pisar 2011-10-24 15:00:26 UTC
And also as <https://rt.cpan.org/Public/Bug/Display.html?id=3316> since 2003.

Comment 14 RHEL Program Management 2012-04-02 14:18:32 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

Comment 15 Petr Šabata 2012-04-02 15:31:57 UTC
A proposed patch has been rejected upstream and there's currently no suggested fix for this issue.  Furthermore, no customers seem to be interested in this at the moment.  I'm closing the bug.


Note You need to log in before you can comment on or make changes to this bug.