You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tested with zig version: zig-linux-x86_64-0.14.0-dev.217+bd7dda0c5
I am currently writing a small tool in Zig which connects to a HTTPS endpoint using the std.http library and interacts with it using various GET and POST requests. The public facing version is provided with SSL by Let's Encrypt.
I have a non-public facing version which is used for testing purposes. I use a self signed certificate with the local instance to ensure that I can still use SSL. A valid certificate chain would be overkill.
The current std.http endpoint does not allow invalid certificates and throws a invalid certficate exception. This behaviour is desirable for production software. After reading the current source code, it appears, there is no option to handle this error gracefully and continue the request even after an invalid certificate. Similiar to the behaviour of curl -k would be great.
The text was updated successfully, but these errors were encountered:
rliebig
changed the title
Allow std.http to ignore SSL certificates for debugging purposes
Allow std.http to ignore invalid SSL certificates for debugging purposes
Nov 14, 2024
Tested with zig version: zig-linux-x86_64-0.14.0-dev.217+bd7dda0c5
I am currently writing a small tool in Zig which connects to a HTTPS endpoint using the std.http library and interacts with it using various GET and POST requests. The public facing version is provided with SSL by Let's Encrypt.
I have a non-public facing version which is used for testing purposes. I use a self signed certificate with the local instance to ensure that I can still use SSL. A valid certificate chain would be overkill.
The current
std.http
endpoint does not allow invalid certificates and throws a invalid certficate exception. This behaviour is desirable for production software. After reading the current source code, it appears, there is no option to handle this error gracefully and continue the request even after an invalid certificate. Similiar to the behaviour ofcurl -k
would be great.The text was updated successfully, but these errors were encountered: