ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
* [ruby-core:73840] [Ruby trunk Feature#12077] Consolidate SSLSocket interface with TCPSocket
       [not found] <redmine.issue-12077.20160216113358@ruby-lang.org>
@ 2016-02-16 11:33 ` tonci.damjanic
  2016-03-06  0:55   ` [ruby-core:74175] " Eric Wong
  2016-02-16 11:34 ` [ruby-core:73841] " tonci.damjanic
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 5+ messages in thread
From: tonci.damjanic @ 2016-02-16 11:33 UTC (permalink / raw
  To: ruby-core

Issue #12077 has been reported by Tonči Damjanić.

----------------------------------------
Feature #12077: Consolidate SSLSocket interface with TCPSocket
https://bugs.ruby-lang.org/issues/12077

* Author: Tonči Damjanić
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
Hello,

Is there a reason why `SSLSocket#read` doesn't work the same as `SSLSocket#sysread` and why there is no `SSLSocket#recv`? Right now it is impossible to have code agnostic in regards to the socket type.

One solution is to monkey-patch `OpenSSL::SSL::SSLSocket` (see lower) to share the same interface as `TCPSocket`, but given the generic names of monkey-patched functions, I'm not sure if they could result with some leaks or strange behavior.

~~~
class OpenSSL::SSL::SSLSocket
  def read(*args)
    sysread(*args)
  end
  
  def write(*args)
    syswrite(*args)
  end
  
  def close
    sysclose
  end
end
~~~

Thoughts?



-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [ruby-core:73841] [Ruby trunk Feature#12077] Consolidate SSLSocket interface with TCPSocket
       [not found] <redmine.issue-12077.20160216113358@ruby-lang.org>
  2016-02-16 11:33 ` [ruby-core:73840] [Ruby trunk Feature#12077] Consolidate SSLSocket interface with TCPSocket tonci.damjanic
@ 2016-02-16 11:34 ` tonci.damjanic
  2016-02-16 11:35 ` [ruby-core:73842] " tonci.damjanic
  2016-02-24 16:08 ` [ruby-core:73963] " tonci.damjanic
  3 siblings, 0 replies; 5+ messages in thread
From: tonci.damjanic @ 2016-02-16 11:34 UTC (permalink / raw
  To: ruby-core

Issue #12077 has been updated by Tonči Damjanić.

Description updated

----------------------------------------
Feature #12077: Consolidate SSLSocket interface with TCPSocket
https://bugs.ruby-lang.org/issues/12077#change-57016

* Author: Tonči Damjanić
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
Hello,

Is there a reason why `SSLSocket#read` doesn't work the same as `SSLSocket#sysread` and why there is no `SSLSocket#recv`? 

Right now it is impossible to have code agnostic in regards to the socket type.

One solution is to monkey-patch `OpenSSL::SSL::SSLSocket` (see lower) to share the same interface as `TCPSocket`, but given the generic names of monkey-patched functions, I'm not sure if they could result with some leaks or strange behavior.

~~~
class OpenSSL::SSL::SSLSocket
  def read(*args)
    sysread(*args)
  end
  
  def write(*args)
    syswrite(*args)
  end
  
  def close
    sysclose
  end
end
~~~

Thoughts?



-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [ruby-core:73842] [Ruby trunk Feature#12077] Consolidate SSLSocket interface with TCPSocket
       [not found] <redmine.issue-12077.20160216113358@ruby-lang.org>
  2016-02-16 11:33 ` [ruby-core:73840] [Ruby trunk Feature#12077] Consolidate SSLSocket interface with TCPSocket tonci.damjanic
  2016-02-16 11:34 ` [ruby-core:73841] " tonci.damjanic
@ 2016-02-16 11:35 ` tonci.damjanic
  2016-02-24 16:08 ` [ruby-core:73963] " tonci.damjanic
  3 siblings, 0 replies; 5+ messages in thread
From: tonci.damjanic @ 2016-02-16 11:35 UTC (permalink / raw
  To: ruby-core

Issue #12077 has been updated by Tonči Damjanić.

Description updated

----------------------------------------
Feature #12077: Consolidate SSLSocket interface with TCPSocket
https://bugs.ruby-lang.org/issues/12077#change-57017

* Author: Tonči Damjanić
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
Hello,

Is there a reason why `SSLSocket#read` doesn't work the same as `SSLSocket#sysread` and why there is no `SSLSocket#recv`? 

Right now it is impossible to have code agnostic in regards to the socket type.

One solution is to monkey-patch `OpenSSL::SSL::SSLSocket` (see lower) to share the same interface as `TCPSocket`, but given the generic names of monkey-patched functions, I'm not sure if they could result with some leaks or strange behavior.

~~~ ruby
class OpenSSL::SSL::SSLSocket
  def read(*args)
    sysread(*args)
  end
  
  def write(*args)
    syswrite(*args)
  end
  
  def close
    sysclose
  end
end
~~~

Thoughts?



-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [ruby-core:73963] [Ruby trunk Feature#12077] Consolidate SSLSocket interface with TCPSocket
       [not found] <redmine.issue-12077.20160216113358@ruby-lang.org>
                   ` (2 preceding siblings ...)
  2016-02-16 11:35 ` [ruby-core:73842] " tonci.damjanic
@ 2016-02-24 16:08 ` tonci.damjanic
  3 siblings, 0 replies; 5+ messages in thread
From: tonci.damjanic @ 2016-02-24 16:08 UTC (permalink / raw
  To: ruby-core

Issue #12077 has been updated by Tonči Damjanić.

Assignee set to ruby-core

----------------------------------------
Feature #12077: Consolidate SSLSocket interface with TCPSocket
https://bugs.ruby-lang.org/issues/12077#change-57116

* Author: Tonči Damjanić
* Status: Open
* Priority: Normal
* Assignee: ruby-core
----------------------------------------
Hello,

Is there a reason why `SSLSocket#read` doesn't work the same as `SSLSocket#sysread` and why there is no `SSLSocket#recv`? 

Right now it is impossible to have code agnostic in regards to the socket type.

One solution is to monkey-patch `OpenSSL::SSL::SSLSocket` (see lower) to share the same interface as `TCPSocket`, but given the generic names of monkey-patched functions, I'm not sure if they could result with some leaks or strange behavior.

~~~ ruby
class OpenSSL::SSL::SSLSocket
  def read(*args)
    sysread(*args)
  end
  
  def write(*args)
    syswrite(*args)
  end
  
  def close
    sysclose
  end
end
~~~

Thoughts?



-- 
https://bugs.ruby-lang.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [ruby-core:74175] Re: [Ruby trunk Feature#12077] Consolidate SSLSocket interface with TCPSocket
  2016-02-16 11:33 ` [ruby-core:73840] [Ruby trunk Feature#12077] Consolidate SSLSocket interface with TCPSocket tonci.damjanic
@ 2016-03-06  0:55   ` Eric Wong
  0 siblings, 0 replies; 5+ messages in thread
From: Eric Wong @ 2016-03-06  0:55 UTC (permalink / raw
  To: ruby-core

tonci.damjanic@gmail.com wrote:
> Is there a reason why `SSLSocket#read` doesn't work the same
> as `SSLSocket#sysread`

Because IO#read and IO#sysread are different, too.  The former
is read-in-full behavior (outside of EOF) while sysread matches
the low-level C interface and allows for partial reads.

Likewise with write vs syswrite regarding write-in-full
behavior.

> and why there is no `SSLSocket#recv`?

Currently, OpenSSL does not provide an interface to recv(2)
which handles flag arguments :<

I too wish for recv(2) and send(2) interfaces which lets me
use MSG_MORE|MSG_DONTWAIT flags.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-03-06  0:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <redmine.issue-12077.20160216113358@ruby-lang.org>
2016-02-16 11:33 ` [ruby-core:73840] [Ruby trunk Feature#12077] Consolidate SSLSocket interface with TCPSocket tonci.damjanic
2016-03-06  0:55   ` [ruby-core:74175] " Eric Wong
2016-02-16 11:34 ` [ruby-core:73841] " tonci.damjanic
2016-02-16 11:35 ` [ruby-core:73842] " tonci.damjanic
2016-02-24 16:08 ` [ruby-core:73963] " tonci.damjanic

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).