Hello,

Would anyone know why http::geturl is failing and complaining with the following url? I have configured the tls and I have registered https as
shown in the first two statements. Thanks in advance.


tls::init -tls1 1 -tls1.1 1 -tls1.2 1
http::register https 443 [list ::tls::socket]
http::geturl https://www.trustpilot.com/review/americanchairs.com


SSL channel "sock08424C80": error: unknown protocol
failed to use socket
while executing
"http::geturl https://www.trustpilot.com/review/americanchairs.com"
("uplevel" body line 1)
invoked from within
"uplevel #0 {http::geturl https://www.trustpilot.com/review/americanchairs.com}"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/15/2022 7:37 AM, saitology9@gmail.com wrote:

Hello,

Would anyone know why http::geturl is failing and complaining with the following url?  I have configured the tls and I have registered https as shown in the first two statements. Thanks in advance.

tls::init -tls1 1 -tls1.1 1 -tls1.2 1
http::register https 443 [list ::tls::socket]
http::geturl https://www.trustpilot.com/review/americanchairs.com

SSL channel "sock08424C80": error: unknown protocol
failed to use socket
    while executing
"http::geturl https://www.trustpilot.com/review/americanchairs.com"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 {http::geturl https://www.trustpilot.com/review/americanchairs.com}"

The answer, as almost always, is to specify the tls version (as you did)
and add the -autoservername option (which you didn't).

(g) 3 % tls::init -tls1 0 -tls1.1 0 -tls1.2 1 -tls1.3 1
-tls1 0 -tls1.1 0 -tls1.2 1 -tls1.3 1
(g) 4 % http::register https 443 [list ::tls::socket -autoservername 1]
443 {::tls::socket -autoservername 1}
(g) 5 % http::geturl https://www.trustpilot.com/review/americanchairs.com ::http::1

I'm not sure why -autoservername is not defaulted to 1. Perhaps some
servers do not support it.

/Ashok

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/14/22 9:57 PM, apn wrote:

The answer, as almost always, is to specify the tls version (as you did)
and add the -autoservername option (which you didn't).

(g) 3 % tls::init -tls1 0 -tls1.1 0 -tls1.2 1 -tls1.3 1
-tls1 0 -tls1.1 0 -tls1.2 1 -tls1.3 1
(g) 4 % http::register https 443 [list ::tls::socket -autoservername 1]
443 {::tls::socket -autoservername 1}
(g) 5 % http::geturl https://www.trustpilot.com/review/americanchairs.com ::http::1

Thanks for your reply. Here is my environment (Windows 10):

% package req http
2.9.1
% package req tls
1.6.7.1
% info patchlevel
8.6.10

Using the same code you used, I am getting the following error:

wrong # args: should be "tls::socket ?options? host port"
while executing
"::tls::socket -autoservername 1 -async www.trustpilot.com 443"
("eval" body line 1)
invoked from within
"eval $defcmd $sockopts $targetAddr"
invoked from within
"http::geturl https://www.trustpilot.com/review/americanchairs.com"
("uplevel" body line 1)
invoked from within
"uplevel #0 {http::geturl https://www.trustpilot.com/review/americanchairs.com}"


If I omit the -autoserver option, then I get a different error which
seems to indicate that you may be using a newer version of tls. Perhaps
this is the answer?

bad option "-tls1.3": must be -cadir, -cafile, -certfile, -cipher,
-command, -dhparams, -keyfile, -model, -password, -require, -request,
-server, -servername, -ssl2, -ssl3, -tls1, -tls1.1 or -tls1.2

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/14/22 11:15 PM, saitology9@gmail.com wrote:

If I omit the -autoserver option, then I get a different error which
seems to indicate that you may be using a newer version of tls.  Perhaps this is the answer?

bad option "-tls1.3": must be -cadir, -cafile, -certfile, -cipher,
-command, -dhparams, -keyfile, -model, -password, -require, -request, -server, -servername, -ssl2, -ssl3, -tls1, -tls1.1 or -tls1.2

Following up on that suspicion, I found a newer version of tls. So now
it's version 1.7.16. With this, "-tls1.3" is still not recognized.
However, when I take it out, and use "-autoservername 1", then the
http::geturl call succeeds.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/15/2022 10:16 AM, saitology9@gmail.com wrote:

On 2/14/22 11:15 PM, saitology9@gmail.com wrote:
Following up on that suspicion, I found a newer version of tls.  So now
it's version 1.7.16. With this, "-tls1.3" is still not recognized.
However, when I take it out, and use "-autoservername 1", then the http::geturl call succeeds.

50% of tls failure reports come from not using the -tls* options, 50%
from not specifying -autoservername and :-) 50% from using hopelessly
outdated versions of TLS.

If you are on Windows, tls 1.7.22 binaries are available from https://sourceforge.net/projects/magicsplat/files/tcltls1.7.22.zip/download

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/02/2022 02:07, saitology9@gmail.com wrote:

Hello,

Would anyone know why http::geturl is failing and complaining with the following url?  I have configured the tls and I have registered https as shown in the first two statements. Thanks in advance.

tls::init -tls1 1 -tls1.1 1 -tls1.2 1
http::register https 443 [list ::tls::socket]
http::geturl https://www.trustpilot.com/review/americanchairs.com

SSL channel "sock08424C80": error: unknown protocol
failed to use socket
    while executing
"http::geturl https://www.trustpilot.com/review/americanchairs.com"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 {http::geturl https://www.trustpilot.com/review/americanchairs.com}"

Short answer: no.

Longer answer: I don't recognise your initilisation/registration. The
wiki (https://wiki.tcl-lang.org/page/HTTPS) recommmends otherwise, and
sure enough

http::register https 443 {tls::socket -autoservername 1}
http::geturl https://www.trustpilot.com/review/americanchairs.com

appears to work just fine - it returns a token and doesn't write
anything to stderr.

Full disclosure: I'm running Tcl 8.6.9, (actually ActiveTcl 8.6.9.0) on
Linux Mint 20.3 Una and typing commands into tkcon. I've got tls 1.7.16
and http 2.9.0. I got errors using your initialisation/registration but
they didn't match yours exactly.

Disclaimer: I don't understand the tls package at all and have only ever
used it as a side effect of fetching data over https, by following the
advice on how to register the protocol. That advice seems to change
slightly over time.

Hope this helps, and good luck.

Alan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/15/22 6:01 AM, Alan Grunwald wrote:

Full disclosure: I'm running Tcl 8.6.9, (actually ActiveTcl 8.6.9.0) on
Linux Mint 20.3 Una and typing commands into tkcon. I've got tls 1.7.16
and http 2.9.0. I got errors using your initialisation/registration but
they didn't match yours exactly.

Disclaimer: I don't understand the tls package at all and have only ever
used it as a side effect of fetching data over https, by following the
advice on how to register the protocol. That advice seems to change
slightly over time.

Hope this helps, and good luck.

Alan

Thank you. I posted the resolution earlier in the hope that someone
finds it useful in the future. It was due to an older version of tls
and the lack of -autoservername. Funny thing is I think the source of
that init command was the same wiki page :-) as you pointed out.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/15/22 12:52 AM, apn wrote:

50% of tls failure reports come from not using the -tls* options, 50%
from not specifying -autoservername and :-) 50% from using hopelessly outdated versions of TLS.

If you are on Windows, tls 1.7.22 binaries are available from https://sourceforge.net/projects/magicsplat/files/tcltls1.7.22.zip/download

Thank you for your help. It is all good now.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

apn <palmtcl@yahoo.com> wrote:

I'm not sure why -autoservername is not defaulted to 1. Perhaps some
servers do not support it.

tls is not limited to use only for https.

Other sockets might use tls and not expect a "Host: ..." line in
the protocol.

Maybe the problem is in putting the "Host:"-header logic into tls
in the first place, rather than directly into http package, but
there might be stringent reasons even for that...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/23/2022 3:22 PM, Andreas Leitgeb wrote:

apn <palmtcl@yahoo.com> wrote:

I'm not sure why -autoservername is not defaulted to 1. Perhaps some
servers do not support it.

tls is not limited to use only for https.

Other sockets might use tls and not expect a "Host: ..." line in
the protocol.

Maybe the problem is in putting the "Host:"-header logic into tls
in the first place, rather than directly into http package, but
there might be stringent reasons even for that...

-autoservername is not tied in any way to HTTP or its Host: header and
thus can't go into the http package. It is sent as part of the *TLS*
Client Hello and part of the TLS protocol for the past two decades. It's independent of the service, whether https or anything else that's
layered on top. If the remote end does not support it, it is free to
just send a fixed cert every time.

/Ashok

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ashok <palmtcl@yahoo.com> wrote:

-autoservername is not tied in any way to HTTP or its Host: header and
thus can't go into the http package. It is sent as part of the *TLS*
Client Hello and part of the TLS protocol for the past two decades. It's independent of the service, whether https or anything else that's
layered on top. If the remote end does not support it, it is free to
just send a fixed cert every time.

Thanks for the clarification.

Seems like my "understanding" of it was pretty far off...

Under these circumstances, I join those who don't understand why
that option isn't on by default.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)