New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed empty and leastSize for OpenSSLStream #1395

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants
@machindertech
Contributor

machindertech commented Feb 2, 2016

The previous implementations were sometimes incorrect, because
SSL_pending only returns the current pending bytes without blocking, and
even if the underlying stream has data available, it might not be
application bytes. Using SSL_peek will block until application
bytes are available or the end of stream has been reached.
See http://permalink.gmane.org/gmane.comp.encryption.openssl.user/6536

Fixed empty and leastSize for OpenSSLStream
The previous implementations were sometimes incorrect, because
SSL_pending only returns the current pending bytes without blocking, and
even if the underlying stream has data available, it might not be
application bytes. Using SSL_peek will block until application
bytes are available or the end of stream has been reached.
See http://permalink.gmane.org/gmane.comp.encryption.openssl.user/6536
@tosttost

This comment has been minimized.

Show comment
Hide comment
@tosttost

tosttost May 22, 2016

Contributor

maybe related, maybe OT: I have trouble with a vibe.d https server. More precisely, a POST file upload to a server running on AWS.

With some OS/browser/connection combinations, the server logs
"Reading from TLS stream was unsuccessful with ret 0" from openssl.d line 279 and the browser gets no response.
If one combination fails, it fails reproducible. For some unknown reason, connecting to a VPN can fix it. After disconnecting from the VPN, the error occures again.

I tried this PR and exept the log line is now triggered in line 280 nothing changed.

Contributor

tosttost commented May 22, 2016

maybe related, maybe OT: I have trouble with a vibe.d https server. More precisely, a POST file upload to a server running on AWS.

With some OS/browser/connection combinations, the server logs
"Reading from TLS stream was unsuccessful with ret 0" from openssl.d line 279 and the browser gets no response.
If one combination fails, it fails reproducible. For some unknown reason, connecting to a VPN can fix it. After disconnecting from the VPN, the error occures again.

I tried this PR and exept the log line is now triggered in line 280 nothing changed.

@tosttost

This comment has been minimized.

Show comment
Hide comment
@tosttost

tosttost Oct 1, 2016

Contributor

It turned out that vibe.d is not to blame for the "Reading from TLS stream was unsuccessful with ret 0" errors we experienced. In fact no POST request with sufficient large body did not made it to the server (EC2 instance). We tried a clean instance and different favours of gnu/linux as well as a variant of python's SimpleHTTPServer... A "first usage of wireshark" investigation seemed to indicate that the request arrived crippled inside the instance (reason unknown).
After switching to another provider, everthing works fine.

Contributor

tosttost commented Oct 1, 2016

It turned out that vibe.d is not to blame for the "Reading from TLS stream was unsuccessful with ret 0" errors we experienced. In fact no POST request with sufficient large body did not made it to the server (EC2 instance). We tried a clean instance and different favours of gnu/linux as well as a variant of python's SimpleHTTPServer... A "first usage of wireshark" investigation seemed to indicate that the request arrived crippled inside the instance (reason unknown).
After switching to another provider, everthing works fine.

@s-ludwig

This comment has been minimized.

Show comment
Hide comment
@s-ludwig

s-ludwig Jul 7, 2017

Member

Sorry for letting this sit here for so long! I somehow associated this with a very obscure solution, but apparently that was another PR for the same bug. This one makes a lot of sense on the other hand. I've cherry picked the change to master as ee35d73.

Member

s-ludwig commented Jul 7, 2017

Sorry for letting this sit here for so long! I somehow associated this with a very obscure solution, but apparently that was another PR for the same bug. This one makes a lot of sense on the other hand. I've cherry picked the change to master as ee35d73.

@s-ludwig s-ludwig closed this Jul 7, 2017

@s-ludwig s-ludwig removed the needs review label Jul 7, 2017

@s-ludwig s-ludwig referenced this pull request Jul 7, 2017

Closed

ssl errors #1124

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment