This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[05:15:42] <aotbot> Is it possible to use Immutables (https://immutables.github.io/) as DataObjects for ServiceProxy definitions?

[17:39:53] <RebelGeek> Hello, I was able to get OAuth2 working in CloudFoundry. The only thing that I need now is for the OAuth2 handler to also make a call to /userinfo to get the user's information PRIOR to hitting the RedirectHandler which will authenticate via authorities. What is the suggested way of doing that?

[23:22:34] <xkr47> temporalfox, got SNI to work

[23:25:30] <xkr47> temporalfox, also managed to automatically extract all aliases from a PEM certificate (Subject CN + SubjectAltNames) so I can automatically register all of them to the keystore

[23:28:55] <temporalfox> good xkr47

[23:29:16] <xkr47> should work with dynamic reconfiguration too

[23:29:27] <xkr47> so now I'm thinking how to expose that..

[23:29:32] <temporalfox> you mean with a KeyManagerFactory ?

[23:29:34] <xkr47> through the event bus perhaps?

[23:29:47] <xkr47> yeah

[23:30:16] <xkr47> I use the code I pasted ~a week ago for KeyManagerFactory

[23:30:21] <temporalfox> I don't know it's your use cases :-)

[23:30:46] * xkr47 reads up on creating microservices with vertx

[23:32:24] <xkr47> so not eventbus but ServiceDiscovery

[23:32:40] <temporalfox> so you are doing some kind of proxy ?

[23:32:55] <temporalfox> smart proxy in front of dynamic services exposed thrhough the proxy ?

[23:33:03] <xkr47> yes: https://github.com/NitorCreations/nitor-backend/

[23:33:06] <temporalfox> cool

[23:33:12] <temporalfox> you might be interested in that

[23:33:19] <xkr47> it does all the http2, auth etc

[23:33:22] <temporalfox> https://github.com/vietj/vertx-http-proxy

[23:33:39] <temporalfox> I'm trying to get in this component, the logic for proxying http

[23:33:51] <xkr47> oh I'm all done with that already

[23:34:05] <xkr47> supports websockets too and http2 on the server side, http1.1 client

[23:34:05] <temporalfox> well actually my goal is to implement a correct proxy

[23:34:11] <xkr47> me too

[23:34:20] <temporalfox> and handle things like error handling

[23:34:21] <xkr47> it's my fourth http proxy since 2001

[23:34:31] <xkr47> yup.. all that covered

[23:34:43] <xkr47> I did find some pipelining bugs in vertx I haven't reported yet

[23:34:51] <temporalfox> I'm actually working on passing a TCP for the proxy

[23:34:58] <temporalfox> TCK

[23:35:03] <xkr47> ?

[23:35:39] <temporalfox> http://coad.measurement-factory.com

[23:35:41] <xkr47> here's the proxy impl https://github.com/NitorCreations/nitor-backend/blob/master/src/main/java/io/nitor/api/backend/proxy/Proxy.java

[23:35:54] <temporalfox> it's a TCK that test correctness of forward / reverse proxy

[23:36:01] <xkr47> :)

[23:36:03] <xkr47> good, thanks

[23:36:08] <temporalfox> and with vertx-http-proxy I'm trying to get all the tests passing

[23:37:03] <temporalfox> also the proxy does not depend on vertx web on purpose

[23:37:15] <temporalfox> it just aims to proxy requests with rewriting

[23:37:19] <xkr47> yeah I understand

[23:37:20] <temporalfox> so a small components that can be reused

[23:37:26] <temporalfox> to implement things like you do

[23:38:17] <xkr47> the use of RoutingContext is quite minimal

[23:38:27] <temporalfox> I recognize indeed that if you proxy a chunked request with http 1.0 you need to buffer the full response

[23:38:29] <xkr47> I could extract that to an interface

[23:38:52] <xkr47> what do you mean ?

[23:39:03] <xkr47> chunked requests don't exist in http/1.0

[23:39:05] <temporalfox> yes

[23:39:15] <temporalfox> so if you proxy a backend chunked response

[23:39:19] <temporalfox> and talk to an http 1.0 client

[23:39:25] <temporalfox> it implies to buffer the full response

[23:39:27] <temporalfox> on the proxy

[23:39:33] <xkr47> ah chunked response, not request :)

[23:39:49] <temporalfox> sorry :-)

[23:39:49] <temporalfox> it's late

[23:39:51] <xkr47> yes.. I have left out HTTP/1.0 support in my proxy

[23:40:15] <xkr47> I have been implementing HTTP/1.0 support too many times already :)

[23:40:34] <xkr47> last time I wrote the whole stack myself using java.nio

[23:41:58] <xkr47> I have filed some 2-3 vertx bugs/PR:s already just to implement the proxy :)

[23:42:20] <temporalfox> ok

[23:42:29] <temporalfox> the vertx-http-proxy also allowed me to find some limits

[23:42:33] <temporalfox> and fix bugs in vertx core

[23:42:39] <temporalfox> maybe I hsould find a list

[23:42:41] <temporalfox> for you

[23:42:52] <xkr47> heh

[23:43:05] <temporalfox> like some incorrect netty requests failure were not handled by vertx exception handler

[23:43:35] <temporalfox> https://github.com/eclipse/vert.x/issues/1862

[23:43:46] <xkr47> I hope to finish the client pipeline PR soon so we can get it fixed.. was quite nasty

[23:44:16] <xkr47> also I'm not sure if it's the best way to do it, but I at least have tests almost ready to reproduce

[23:44:23] <temporalfox> HttpClient leaves connection open on websocket request failure (resource leak)

[23:44:25] <temporalfox> that was you

[23:44:36] <temporalfox> if you provide at least a reproducer

[23:44:37] <temporalfox> it's cool

[23:44:54] <temporalfox> this one too

[23:44:55] <temporalfox> https://github.com/eclipse/vert.x/issues/1727

[23:44:58] <temporalfox> “Too long max headers results in empty reply instead of 400 response”

[23:45:11] <temporalfox> https://github.com/eclipse/vert.x/issues/1724

[23:45:15] <temporalfox> Allow to configure maxInitialLineLength and maxHeaderSize in the HttpClient

[23:45:37] <xkr47> nice

[23:46:38] <temporalfox> anyway if you feel to contribute to vertx-http-proxy to factor this proxy logic in a single place it would be great :-)

[23:46:49] <temporalfox> so this could become a small vertx component

[23:46:57] <temporalfox> that helps people implementing case like you

[23:47:09] <temporalfox> for building api management / api gateway / smart proxies

[23:47:21] <xkr47> yeah it would be good

[23:47:36] <xkr47> so I just paste my implementation over, right? :D :D :D

[23:47:49] <temporalfox> if it passes the full coad TCK, why not

[23:47:49] <temporalfox> :-)

[23:48:07] <xkr47> want to finish this SNI stuff first

[23:48:25] <xkr47> so I can then finish letsencrypt with the tls-sni challenge

[23:48:36] <temporalfox> ah yes

[23:49:13] <xkr47> I see that microservices is a separate bundle

[23:49:33] <xkr47> so I'm wondering whether it would be better to use the event bus as an interface to the dynamic keystore configuration

[23:50:13] <xkr47> like vertx.eventBus().publish(“keystore.add”, new Object[] { certChain, privateKey });

[23:51:12] <temporalfox> why don't you use rather vertx clsutered data ?

[23:51:31] <temporalfox> if it needs a certificate and does not find it locally, it can lookup in shared data

[23:51:37] <temporalfox> and cache the result locally for a while

[23:51:50] <xkr47> I don't know that yet

[23:52:24] <xkr47> what kind of setup were you envisioning?

[23:52:52] <xkr47> keep certs on one node only and share over cluster?

[23:53:17] <temporalfox> I don't know about your global architecture actually

[23:53:35] <temporalfox> iut seems that you are trying to get metadata from dynamic service

[23:53:38] <xkr47> yeah.. our proxy is pretty stateless

[23:53:40] <temporalfox> like a store

[23:54:49] <xkr47> I'll do a quick hack with event bus first to see if the whole shebang works

[23:54:51] <xkr47> ^^

[23:55:11] <temporalfox> ok

[23:55:19] <temporalfox> are you doing this for fun ?

[23:55:45] <xkr47> vertx is always fun, wdym? :)

[23:56:11] <temporalfox> I mean are you implementing a business case ?

[23:56:11] <xkr47> the letsencrypt stuff is both for my home server and for our company servers

[23:56:16] <temporalfox> ok

[23:56:24] <xkr47> the tls-sni thing is not strictly necessary

[23:56:38] <xkr47> so I'm trying that out for fun

[23:56:46] <xkr47> I could easily just implement the http-01 challenge instead

[23:57:03] <temporalfox> yes it seems enough :-)

[23:57:08] <temporalfox> and less convoluted

[23:57:59] <xkr47> well.. our port 80 service is currently redirecting everything to https and runs in a separate proces (because of systemd which can only pass a single serversocket to a java instance)

[23:58:18] <xkr47> so we have two systemd services, one for 80 and one for 443

[23:58:33] <xkr47> so it would be more .. demanding .. to coordinate the certificate challenge between two jvms

[23:58:51] <xkr47> so I though implementing the tls-sni would let me handle it all directly in-jvm

[23:59:15] <temporalfox> ok

[23:59:40] <xkr47> I'm not a big systemd fan, but that's what we use on the company servers