I think involuntary introducing https in systems not expecting it, and not in need for it, is not the way to go Lot of simple scripts performing automated tests, configure embedded devices, etc, will break because the server not talking https Secure systems will specify https:// explicitly and not rely on good intentions of lower layer
I can imagine an option for specifying the default fallback, one one can set it to prefer https:// as a safety net that can be applied, to catch forgotten urls without a scheme deep down in an application, or provide a quick 'flip' between encrypted an unencrypted mode. Erik -----Original Message----- From: curl-library <[email protected]> On Behalf Of Daniel Stenberg via curl-library Sent: woensdag 19 september 2018 11:02 To: libcurl hacking <[email protected]> Cc: Daniel Stenberg <[email protected]> Subject: Deprecate falling back to http:// ? Hi! The URL parser in libcurl accepts URLs without a scheme, the "text://" part of URLs. If no scheme is specified, libcurl guesses which scheme that was intended based on some basic hueristics and if nothing matches it falls back to plain old "http://";. In this day and age of growing HTTPS use and slow decay of plain HTTP, maybe it is time to change the fallback in libcurl and make it instead go with HTTPS if nothing else matches? I'm a little scared this might hurt a lot of users running scripts relying on this since forever. (Brought to attention since I'm adding the CURLU_GUESS_SCHEME to the URL API in https://github.com/curl/curl/pull/3018) Thoughts? -- / daniel.haxx.se ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
