Allow certificate based client authentication

[adamretter]

Closes https://github.com/expath/expath-cg/issues/76

I have given us quite a lot of wiggle room on this one, by making the actual details implementation defined (which I normally avoid).

However I have also restricted it a little by saying Java implementations SHOULD do it the same way. There pretty much seems to be only one way to do it in Java anyway, i.e. via key stores, both the JDK HTTP classes and the Apache HttpClient classes implement it.

It seems likely to me that only the Java XQuery/XSLT processors will implement this anyway (e.g. Saxon, BaseX, and eXist-db). The implementation defined though, allows for any other language implementation or a different Java implementation too.

[ChristianGruen]

Sounds all reasonable. I may add some more feedback once we’ll implement this.

[adamretter]

@christiangruen would you be interested in a shared implementation core? Like we had for the first spec? I would be happy to implement, then in future we fix bugs once, rather than in two or more implementations. Happy to use a licence which works for BaseX e.g. BSD

[ChristianGruen]

Hi Adam, while I clearly see advantages of having a shared code base – and I appreciate a lot that you would take over the task of implementing it – we have some tendency in BaseX to tightly couple our internal core optimizations with module features, and to keep the code base as small as possible (as you may know the BaseX core library, which includes the implementations of various EXPath modules, is completely self-contained and does not depend on external libraries so far – although some can be embedded and will be dynamically detected, e.g. for RelaxNG validation etc.). Some questions that arise spontaneously: Could the HTTP Client be implemented without dependencies to additional libraries? And can we ensure that implementation-specific optimizations for streaming data will still be available in a shared implementation?

Maybe I’m overcautious here. I should definitely spend some time to look at the existing implementation for version 1.0.

[adamretter]

@christiangruen please do NOT look at the existing HTTP Client implementation, it's not what I would have liked.

We can certainly do it without dependencies by using the core java stuff for http if that is a requirement from you. Only issue would be HTTP/2 which only appears in Java SDK from Java 9 onwards. I think BaseX is Java 8 language level still?

Also in eXist we really appreciate connection pooling, chunked requests, and pipelining, for performance, which is best provided by libraries like Apache IMHO.

Regards implementation specific optimizations for streaming, we just need to define an interface type, this could be as simple as a Java Reader or InputStrean, or something more abstract if needed.

The core implementation should just be Java functions for each XQuery function, with no XQuery specifics. Then you can add an adapter for BaseX and us for eXist-db.

[fgeorges]

I do not know the details of these aspects on Java, but it does not seem crazy to me, if this is an implementation-defined feature, to add an appendix in the spec itself giving the guidelines or details for a Java implementation (appendix that could be normative or not.)

[adamretter]

Sure if the spec text starts getting unwieldy, we could happily move that example to an Appendix. Let's save such things for the final proof reading and editing rounds

[fgeorges]

Well, I guess my point was that adding details specific to Java is OK, as long as it is in an appendix :-)