On Thu, Apr 16, 2020 at 12:36:24AM +0200, Mark Windshield via curl-library
wrote:
> I'm trying to not send TLS 1.3 Ciphers when making a request through
> libcurl (but have the option to set them), I tried compiling openssl with
> 'define TLS_DEFAULT_CIPHERSUITES " " ' instead of it containing
On 4/15/2020 6:36 PM, Mark Windshield via curl-library wrote:
I'm trying to not send TLS 1.3 Ciphers when making a request through
libcurl (but have the option to set them), I tried compiling openssl
with 'define TLS_DEFAULT_CIPHERSUITES " " ' instead of it containing
the three "default"
Hi ,
Yes , technically but we need specific requirement to support TLS only for
initial negotiations and then bring down TLS tunnel.
we tried stunnel as well we seem to get empty response from server after
initial negiotiations curl: (52) Empty reply from server.
Hence if we are able to handshake
Hello,
I'm trying to not send TLS 1.3 Ciphers when making a request through
libcurl (but have the option to set them), I tried compiling openssl with
'define TLS_DEFAULT_CIPHERSUITES " " ' instead of it containing the three
"default" ciphers, but when replacing openssl and using liubcurl with
On Wed, 15 Apr 2020, Anand Sridharan wrote:
we would need TLS for initial negotiations only then data transfer to happen
with normal raw socket , hence stunnel may not totally help us.
This statement puzzled me so I need to ask. When you use a SOCKS proxy there's
just that single connection
On Wed, 15 Apr 2020, Christoph Krey via curl-library wrote:
in MQTT protocol, the server may start to send PUBLISH messages (especially
if those are retained) before replying with SUBACK to a SUBSCRIBE.
The current implementation in curl waits for a SUBACK or DISCONNECT after
the SUBSCRIBE.
Thanks Daniel , updated comments
On Tue, Apr 14, 2020 at 11:29 PM Daniel Stenberg wrote:
> On Tue, 14 Apr 2020, Anand Sridharan via curl-library wrote:
>
> > Method 1 - use existing api's used for http proxy but remove any
> conditions
> > specific for HTTPS proxy.(wireshark:
Hello,
>
> I tried doing:
>
> ./curl 'mqtt://test.mosquitto.org/de.wsv/pegel/cm/ems/emshoern' --output -
>
> That topic currently has a retained message with content "582". The
> response I get from curl is:
>
> curl: (8) Weird server reply
> de.wsv/pegel/cm/ems/emshoern582
in MQTT protocol,
On Wed, 15 Apr 2020, Daniel Stenberg via curl-library wrote:
I cannot reproduce that. Doing that command line here seems to get a partial
response and then it sits waiting for the rest:
After looking at what I wrote there, it struck me that it doesn't actually
"wait for the rest". It gets 33
On Tue, 14 Apr 2020, Anand Sridharan via curl-library wrote:
Method 1 - use existing api's used for http proxy but remove any conditions
specific for HTTPS proxy.(wireshark: lo_sslversion.pcap)
- SSL upgrade of existing socket using curl API’s
curl_ssl_connect_nonblocking and
On Wed, 15 Apr 2020, Roger Light via curl-library wrote:
./curl 'mqtt://test.mosquitto.org/de.wsv/pegel/cm/ems/emshoern' --output -
That topic currently has a retained message with content "582". The
response I get from curl is:
curl: (8) Weird server reply
de.wsv/pegel/cm/ems/emshoern582
I
11 matches
Mail list logo
