Re: https support

2020-08-17 Thread Michael Behrisch

Am 2020-08-17 14:04, schrieb Roger Leigh:

I think that CURL should work just fine on Windows.  The
socket/winsock options are plain sockets with no SSL support.


OK, then curl seems to be the way forward.


I did suggest a couple of months back that in the current day and age
of HTTPS everywhere, we might want to consider removing the built-in
socket support and only provide netaccessors which support HTTPS. 
This would guarantee working HTTPS support (the alternative being no
network support at all).  See
https://issues.apache.org/jira/browse/XERCESC-2207


I support that idea.

Best regards,
Michael

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: https support

2020-08-17 Thread Roger Leigh

On 17/08/2020 10:22, Michael Behrisch wrote:


Hi,
we are currently using Xerces-C++ on Linux, Windows and MacOS for
parsing XML inputs and validating it against schemas. The schemas (like
https://sumo.dlr.de/xsd/routes_file.xsd) are on a public web server
which enforces https and I have some questions about Xerces-C++ here.

I understand that the https support depends on the net accessor used but
it is not clear to me which accessor really supports it.
Libcurl probably does (if built with ssl enabled), so we are fine under
Linux because it is generally available?

Winsock does not support https?

Can I find out at runtime whether I am using a Xerces-C++ with https
support (other than trial and error) to give at least a meaningful error
message?

I saw that there are libcurl implementations for Windows as well:
https://stackoverflow.com/questions/53861300/how-do-you-properly-install-libcurl-for-use-in-visual-studio-2017
but the docs say libcurl does not work with Windows. Did nobody try yet
or are there any major roadblocks?



Hi Michael,


I think that CURL should work just fine on Windows.  The socket/winsock 
options are plain sockets with no SSL support.



Looking at how the netaccessor selection is done, it's completely 
compile-time and the setting is in config.h which isn't installed, so 
it's not possible to determine the netaccessor in use at runtime or 
compile time as an end-user of Xerces-C++.  If the netaccessor symbols 
get exported you could possibly see if you can access the appropriate 
symbols, but it would be both hacky and fragile to do so.



I did suggest a couple of months back that in the current day and age of 
HTTPS everywhere, we might want to consider removing the built-in socket 
support and only provide netaccessors which support HTTPS.  This would 
guarantee working HTTPS support (the alternative being no network 
support at all).  See https://issues.apache.org/jira/browse/XERCESC-2207



Kind regards,

Roger


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org