> On 28 Feb 2015, at 11:08, Johan Brichau <[hidden email]> wrote:
>
> Hi Sabine,
>
> I took a closer look and indeed, that strategy probably only works in our usecase where it’s a download of a zip tarball from github that fails in the Metacello code.
> Because on the second try, the github cache was already created, Metacello no longer sends the request to github and we pass by it.
>
> So, our ‘workaround’ does not apply outside of downloading from github.
>
> It does seem to be the same problem though. The SSL plugin is reporting an error while the connection closed just fine.
> If that’s the case, the culprit is the SSL plugin…
>
> Johan
>
>> On 28 Feb 2015, at 10:44, Sabine Manaa <[hidden email]> wrote:
>>
>> Hi Johan,
>>
>> I tried this: I put an exception handler around and on error, I tried again, but the error still occurs.
>>
>> Regards
>> Sabine
>>
>> 2015-02-28 8:54 GMT+01:00 Johan Brichau-2 [via Smalltalk] <[hidden email]>:
>> This sounds familiar to what we reported a while back:
>> http://forum.world.st/Mac-sqDecryptSSL-returning-SQSSL-GENERIC-ERROR-on-errSSLClosedGraceful-from-SSLRead-td4785735.html
>>
>> Unfortunately, we did not investigate any further. Instead, we work around the bug by just retrying the connection on this failure as it always works on a second try.
>>
>> Johan
>>
>>> On 27 Feb 2015, at 23:36, Sven Van Caekenberghe <[hidden email]> wrote:
>>>
>>>
>>>> On 27 Feb 2015, at 21:18, Sabine Manaa <[hidden email]> wrote:
>>>>
>>>> Hi Sven,
>>>>
>>>> thank you for your hints.
>>>>
>>>> Indeed, the variable @in of ZdcSecureSocketStream has the string  "ZnInvalidUTF8: Illegal leading byte for utf-8 encoding" in its utf-8 variable.
>>>
>>> That is normal: the in buffer contains encrypted binary data, the out buffer will contain the cleartext (but still in binary).
>>>
>>>> Can you tell me, what to add to the pharo code that the encoding is correct/so that is equal to the curl command?
>>>
>>> I don't think there is an encoding problem: the charset is set to utf-8 which will be picked up. Besides, the returned content is plain ascii anyway.
>>>
>>> The issue is probably the Connection:close and the missing Content-Length. This means that the HTTPS stream has to be read until the end. I have seen this fail in the past in rare cases.
>>>
>>> Are you on Windows ?
>>>
>>> Could you try on Linux ?
>>>
>>>> comparison of headers: they seem to be equal, also the content type is in both cases 'application/json;charset=UTF-8'
>>>> The ZnResponse headers:
>>>> a ZnHeaders(
>>>> same 'Cache-Control'->#('no-cache, no-store, max-age=0, must-revalidate' 'no-store')
>>>> same 'Connection'->'close'
>>>> same 'Content-Type'->'application/json;charset=UTF-8'
>>>> same 'Date'->'Fri, 27 Feb 2015 20:02:40 GMT'
>>>> same 'Expires'->'0'
>>>> same 'Pragma'->#('no-cache' 'no-cache')
>>>> same 'Set-Cookie'->'crbid=10.1.8.3:49247_mt03.prod.gini.net; path=/'
>>>> same 'Strict-Transport-Security'->'max-age=31536000 ; includeSubDomains'
>>>> same 'X-Application-Context'->'0.3:8080'
>>>> same 'X-Content-Type-Options'->'nosniff'
>>>> same 'X-Frame-Options'->'DENY'
>>>> same 'X-Xss-Protection'->'1; mode=block' )
>>>>
>>>> result of curl command at command line
>>>> < HTTP/1.1 200 OK
>>>> same < Date: Fri, 27 Feb 2015 17:58:37 GMT
>>>> same < X-Content-Type-Options: nosniff
>>>> same < X-XSS-Protection: 1; mode=block
>>>> same < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
>>>> same < Pragma: no-cache
>>>> same < Expires: 0
>>>> same < Strict-Transport-Security: max-age=31536000 ; includeSubDomains
>>>> same < X-Frame-Options: DENY
>>>> same < X-Application-Context: 0.3:8080
>>>> < Cache-Control: no-store
>>>> < Pragma: no-cache
>>>> same < Content-Type: application/json;charset=UTF-8
>>>> same < Connection: close
>>>> same < Set-Cookie: crbid=10.1.8.5:49387_mt05.prod.gini.net; path=/
>>>>
>>>> regards
>>>> sabine
>>>>
>>>> 2015-02-27 16:58 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>:
>>>> Sabine,
>>>>
>>>>> On 27 Feb 2015, at 16:36, Sabine Manaa <[hidden email]> wrote:
>>>>>
>>>>> Hi Sven,
>>>>> Hi all,
>>>>>
>>>>> I try to send a curl command (which works at command line) from Pharo.
>>>>> I get the error: "SSL Exception: decrypt failed code:5"
>>>>>
>>>>> The working command line command is:
>>>>>
>>>>> curl -v  -H 'Accept: application/json' -u 'aUser:aPassword'
>>>>> 'https://user.xxx.net/oauth/token?grant_type=client_credentials'
>>>>>
>>>>> the result is something like:
>>>>> {"access_token":"a31xxxa-2a22-4xx6c-938d-2bd3ae4a0629","token_type":"bearer","expires_in":42095,"scope":"write"}
>>>>>
>>>>> My current Pharo code is:
>>>>>       | theZnClient |
>>>>>       theZnClient := ZnClient new
>>>>>               systemPolicy ;
>>>>>               https;
>>>>>               host: 'user.xxx.net';
>>>>>               path: 'oauth/token?grant_type=client_credentials';
>>>>>               username: 'aUser' password: 'aPassword';
>>>>>               accept: ZnMimeType applicationJson;
>>>>>               get.
>>>>>       theZnClient inspect close.
>>>>>
>>>>> 'aPassword' and 'aUser' and xxx.net was replaced by me for security reasons.
>>>>>
>>>>> In Pharo, I get a walkback with the error message
>>>>> 'SSL Exception: decrypt failed [code:-5]'
>>>>>
>>>>> But I see, that the ZdcSecureSocketStream has the correct result
>>>>> ({"access_token":...":"write"}) in its collection attribute at
>>>>> utf-8 string and at latin1-string
>>>>>
>>>>> so, the request is done and the result is available but then it fails here:
>>>>> ZdcSecureSocketStream(Object)>>error:
>>>>> ZdcSecureSocketStream>>sslException:code:
>>>>> ZdcSecureSocketStream>>fillBytes:startingAt:count: in Block: [ ...
>>>>> ZdcSecureSocketStream>>fillBytes:startingAt:count:
>>>>> ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBufferNoWait
>>>>> ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer
>>>>> ZdcSecureSocketStream(ZdcOptimizedSocketStream)>>readInto:startingAt:count:
>>>>> ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream:
>>>>> ZnUTF8Encoder>>readInto:startingAt:count:fromStream:
>>>>>
>>>>> Sven, I could send you the 'aPassword' and 'aUser' and the url by private
>>>>> message. It would be fine if you could have a short look at it.
>>>> The fact that there is readable text in the buffer of the ZdcSecureSocketStream is good, because it means that things basically work.
>>>>
>>>> One reason why this is failing might be that Zn tries to read more than there is available in the stream, when the content-length does not match. Encoding problems could be part of the problem too.
>>>>
>>>> Could you compare curl -v or curl -D - output with the request/response headers in Pharo ? Look for content-length and compare that with what it already read or not. Is the connection kept alive ? Also look at content-type and see if there is any charset encoding after application/json.
>>>>
>>>> Sven
>>>>
>>>>> Regards
>>>>> Sabine
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808345.html
>>>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> If you reply to this email, your message will be added to the discussion below:
>>>> http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808353.html
>>>> To start a new topic under Pharo Smalltalk Users, email [hidden email]
>>>> To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here.
>>>> NAML
>>>>
>>>>
>>>> View this message in context: Re: Zinc SSL Exception: decrypt failed code:5
>>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> If you reply to this email, your message will be added to the discussion below:
>> http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808485.html
>> To start a new topic under Pharo Smalltalk Users, email [hidden email]
>> To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here.
>> NAML
>>
>>
>> View this message in context: Re: Zinc SSL Exception: decrypt failed code:5
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>