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

[00:03:00] * ChanServ sets mode: +o temporalfox [00:04:03] <AlexLehm> temporalfox: ok, i think the pr for dns is ok, however I am probably not the best person for netty [00:05:32] <temporalfox> actually the same PR was accepted in Netty [00:06:11] <temporalfox> https://github.com/netty/netty/commit/804e058e27e16e346b565ce4490f6177574e267d [00:06:27] <temporalfox> it's not exactly the same PR [00:06:47] <temporalfox> but the overall netty approach has been reviewed by norman maurer [00:24:02] <AlexLehm> temporalfox: i have changed the pr based on your comments [00:24:12] <temporalfox> thanks [00:24:19] <temporalfox> going to merge it, so it's done :-) [00:25:26] <temporalfox> I think that it shold call [00:25:32] <temporalfox> testComplete() [00:25:38] <temporalfox> and not fail(); [00:25:44] <temporalfox> in [00:25:45] <temporalfox> / request is supposed to fail [00:25:46] <temporalfox> + fail(); [00:27:08] <AlexLehm> no, the request should fail, which means that the test fails if the request is successful [00:27:32] <temporalfox> ah yes [00:27:38] <temporalfox> sorry [00:30:25] <temporalfox> thanks AlexLehm for the work [00:30:32] <AlexLehm> thanks for merging it [00:30:38] <temporalfox> well for the contrib :-) [00:30:42] <temporalfox> I hate to say “work” [18:04:19] <gemmellr> temporalfox: are all the modules being included for 3.3.1? [18:04:39] <gemmellr> temporalfox: I've made some doc updates, just wondering if I need to add something to the umbrella issue to get it included [18:10:35] <temporalfox> gemmellr hi, yes it will be included - I don't think you need if you just updated docs [18:10:55] <temporalfox> gemmellr the goal of the release is to fix what is blocking for using vertx [18:11:31] <gemmellr> temporalfox: no, not strictly needed, just wondering if the docs will make it to the site without me doing anything [18:11:43] <temporalfox> yes they will make it [18:11:49] <temporalfox> we had other doc edits [18:12:03] <temporalfox> feel free to add to https://github.com/vert-x3/issues/issues/132 if you want [18:12:10] <temporalfox> you can see “documentation fixes” [18:12:43] <gemmellr> temporalfox: yes, I added something previously, but I raised a PR for that whereas I neglected to this time ;) [18:12:56] <temporalfox> not a big deal imho [18:12:58] <gemmellr> temporalfox: will add a note [18:20:03] <temporalfox> thanks [20:29:14] <ChicagoJohn> anyone on? i have a quick question regarding vertx rx [20:29:59] <ChicagoJohn> i believe i have figured out a way to chain successive calls. call X. Call Y with result of X [20:30:30] <ChicagoJohn> and i am looking for a quick review if i am either correct, or doing it incorrectly [20:31:25] <ChicagoJohn> Observable.create(sub → { [20:31:25] <ChicagoJohn> vertx.createHttpClient(getClientOptions()).get(endpoint).handler(response → { [20:31:25] <ChicagoJohn> System.out.println(“called”); [20:31:25] <ChicagoJohn> sub.onNext(response); [20:31:25] <ChicagoJohn> sub.onCompleted(); [20:31:25] <ChicagoJohn> }).end(); [20:31:25] <ChicagoJohn> }).flatMap(resp → { [20:31:26] <ChicagoJohn> return Observable.<HttpClientResponse>create(sub → { [20:31:26] <ChicagoJohn> vertx.createHttpClient(getClientOptions()).get(endpoint).handler(response → { [20:31:27] <ChicagoJohn> System.out.println(“called again”); [20:31:27] <ChicagoJohn> sub.onNext(response); [20:31:28] <ChicagoJohn> sub.onCompleted(); [21:56:00] * ChanServ sets mode: +o temporal_

[22:51:42] <AlexLehm> temporal_: I have found an issue with the proxy (or rather the guy who reported the proxy exception issue has found it), the connect proxy does not make sense when using http, since the proxy will not allow that

[22:51:59] <temporal_> AlexLehm hi

[22:52:02] <AlexLehm> hi

[22:52:06] <temporal_> why it does not make sense ?

[22:52:54] <AlexLehm> the protocol does allow to use CONNECT www.google.de:80, but any proxy will deny the request since it tries to limit the connects to common https ports

[22:53:32] <AlexLehm> this is either for security reasons or to force usage of the proxy protocol e.g. GET on the proxy

[22:53:48] <temporal_> I don't understand

[22:53:55] <temporal_> can you explain the exact configuration ?

[22:54:20] <temporal_> who connects to what :-)

[22:54:31] <AlexLehm> the CONNECT method is usually only allowed to connect to specific ports

[22:55:12] <AlexLehm> the client connects to the proxy server (with the CONNECT method), the proxy connects to the target server/port and establishes a bidirectional tunnel

[22:55:38] <temporal_> yes it is used to create a tunnel

[22:55:45] <AlexLehm> the client is expected to do ssl over the tunnel, but that is usually not enforced, so the client could use any protocol

[22:56:00] <temporal_> I think that with connect

[22:56:17] <temporal_> the proxy should not care of the what is inside

[22:56:30] <temporal_> it just passes the data and the traffic is opaque

[22:56:38] <temporal_> to the proxy

[22:57:31] <AlexLehm> yes, but that is a security problem, the proxy might be able to connect to external hosts that the internal servers may not connect to

[22:57:47] <AlexLehm> for example external mail servers

[22:57:51] <temporal_> yes indeed that the idea of the proxy :-)

[22:58:17] <temporal_> and right now what we have done allow to use the proxy with NetClient

[22:58:46] <AlexLehm> well, yes, but the proxy is supposed to work for HTTP/HTTPS only, so the CONNECT proxy is expected to use ssl and the connections not using ssl are supposed to use a different protocol

[22:59:10] <temporal_> you mean that the client is expected to use SSL inside the tunnel

[22:59:19] <AlexLehm> yes

[22:59:25] <AlexLehm> and it is supposed to connect to ssl ports only

[22:59:40] <temporal_> what we do have right now does not preclude that

[22:59:42] <temporal_> right ?

[22:59:53] <AlexLehm> yes, that is correct

[23:00:09] <temporal_> so it's fine

[23:00:17] <temporal_> if someone wrongly uses the proxy then it's ok

[23:00:29] <AlexLehm> well, not really

[23:00:32] <temporal_> one mantra of vertx is that it should not prevent you from doing what you want to do

[23:00:43] <temporal_> however we should document how the proxy should be used correctly

[23:00:47] <temporal_> with an example

[23:00:53] <temporal_> that's perhaps what we are missing

[23:01:13] <AlexLehm> yes, however the expectation of a proxy request with HttpClient for a request towards a http url is different

[23:01:43] <AlexLehm> btw, that is what I wanted to suggest to add for now, since fixing the issue will require some work and that will take me some time

[23:01:56] <temporal_> what issue do you want to fix precisely ?

[23:02:30] <AlexLehm> that is what I mean to explain, the expectation is that the proxy is accessed in a different protocol when it is not http

[23:03:00] <AlexLehm> assume you have Firefox and you are inside an intranet network at a company that does not allow http/https connections to the internet

[23:03:04] <AlexLehm> (like HP where I work)

[23:03:33] <AlexLehm> the Firefox is configured to use a http proxy for non-secure urls and a https proxy (connect proxy) for secure urls

[23:04:19] <AlexLehm> the protocol for the non-secure urls is completely different from the CONNECT protocol, it may be the same proxy on the same port, but the protocol does not use CONNECT method for http urls

[23:04:55] <temporal_> ok

[23:05:08] <temporal_> and we don't address this case

[23:05:10] <AlexLehm> rather is uses e.g. a GET request to the absolute url and the proxy will decode the request and do the normal GET request to the original server (or anther proxy)

[23:05:31] <temporal_> I see what you mean now

[23:05:38] <temporal_> so we should rename

[23:05:45] <AlexLehm> yes, i figured that the proxy will only be applied to the https case, but it turns out it tries to do it for the GET request as well and that has to be handled differently

[23:05:45] <temporal_> ProxyType.HTTP to ProxyType.HTTP_CONNECT

[23:06:32] <AlexLehm> the proxytype HTTP is ok, the handling of the protocol has to be different in the HttpClient, basically it has to distinguish between http and https and change the protocol

[23:06:50] <temporal_> yes but then I would prefer to use HTTP_CONNECT and HTTP

[23:06:55] <temporal_> and make the distinction

[23:07:32] <temporal_> so one may want to do HTTP_CONNECT with non TLS ?

[23:07:40] <temporal_> need to think about it

[23:09:01] <temporal_> you mean that proxy with http that the URL in the HTTP request

[23:09:07] <temporal_> would be an absolute URL

[23:09:24] <temporal_> but Host header would be the proxy host

[23:10:55] <temporal_> http://stackoverflow.com/questions/11697943/when-should-one-use-connect-and-get-http-methods-at-http-proxy-server

[23:10:58] <temporal_> one say

[23:11:13] <temporal_> A CONNECT request urges your proxy to establish an HTTP tunnel to the remote end-point. Usually is it used for SSL connections, though it can be used with HTTP as well (used for the purposes of proxy-chaining and tunneling)

[23:11:24] <AlexLehm> the host header is rewritten by the proxy anyway, a proxy request is valid without any headers it ihnk

[23:12:46] <AlexLehm> ah, that description is not quite correct, a CONNECT request asks the proxy to establish a tcp tunnel to the remote end point

[23:13:02] <temporal_> yes connect just ask for tunnel

[23:13:06] <AlexLehm> the tunnel has no limitation for HTTP

[23:13:08] <temporal_> and then HTTP or HTTPS traffic

[23:13:27] <AlexLehm> yes, for example it is possible to use a tunnel for SMTP but the proxy config will deny that as well

[23:14:00] <AlexLehm> when using NetClient, that is possible and when using SOCKS proxy that is the right thing to do

[23:14:26] <temporal_> well, I think we should not preclude the things to do :-)

[23:15:18] <AlexLehm> yes, but currently the normal http proxy functionality is missing

[23:16:25] <temporal_> yes that's why I think we should rename ProxyType.HTTP → ProxyType.CONNECT

[23:16:59] <temporal_> do you have aresource explaining the behavior of HTTP proxy without connect ?

[23:17:25] <AlexLehm> i think that is a rfc, let me check

[23:17:44] <temporal_> I'm jsut looking for an example of requests

[23:17:46] <temporal_> something concrete :-)

[23:17:50] <temporal_> I can read RFC after

[23:18:15] <temporal_> maybe I should try with my browser

[23:18:29] <temporal_> and then use wireshark

[23:18:34] <temporal_> or whatever

[23:19:11] <temporal_> right now in FF I see

[23:19:16] <temporal_> HTTP Proxy

[23:19:19] <temporal_> SSL Proxy

[23:19:32] <temporal_> and SOCKS proxy

[23:19:40] <temporal_> there is also FTP proxy

[23:21:58] <AlexLehm> HTTP proxy is the GET proxy we are talking about

[23:22:03] <AlexLehm> SSL proxy is the CONNECT proxy

[23:22:06] <temporal_> so what I get is

[23:22:13] <AlexLehm> and SOCKS proxy is a different protocol

[23:22:29] <temporal_> GET http://www.google.com HTTP/1.1

[23:22:29] <AlexLehm> ftp proxy is probably a HTTP protocol to access ftp servers

[23:22:32] <temporal_> just to confirm

[23:22:34] <AlexLehm> yes

[23:22:48] <temporal_> I think we need to rename ProxyType.HTTP

[23:23:06] <temporal_> let's see how it is named in Chrome

[23:23:38] <temporal_> so chrome relies on OSX config

[23:23:38] <temporal_> that name it

[23:23:46] <temporal_> Web Proxy

[23:23:52] <temporal_> Secure Web Proxy

[23:24:00] <temporal_> with HTTP and HTTPS

[23:24:06] <temporal_> in ()

[23:25:38] <temporal_> would it work from HttpClient to do

[23:25:56] <temporal_> client.get(8080, “localhost”: “http://www.google.com”, resp → {});

[23:25:58] <temporal_> I guess so

[23:26:45] <AlexLehm> if localhost:8080 is the proxy?

[23:26:49] <temporal_> yes

[23:27:19] <AlexLehm> yes

[23:27:24] <AlexLehm> well currently not

[23:28:36] <AlexLehm> if it were implemented, I would expect the follow to work

[23:29:04] <AlexLehm> HttpClient.setProxy(new ProxyOptions().setHost(“localhost”).setPort(8080).setProxyType(ProxyType.HTTP))

[23:29:37] <AlexLehm> and then client.getAbs(“http://www.google.de” …) to use the Web Proxy protocol

[23:29:48] <temporal_> yes it should work too

[23:29:50] <AlexLehm> and client.getAbs(“https://www.google.de”) to use the tunnel protocol

[23:30:00] <temporal_> no that's not possible

[23:30:07] <temporal_> because you setSecure on the client

[23:30:28] <AlexLehm> with getAbs as well?

[23:31:07] <temporal_> checking

[23:31:31] <AlexLehm> ok, then lets say with setProxy(…).setSsl(true) it should select the web secure protocol (with CONNECT) and without setSsl, it should select the web proxy protocol

[23:33:12] <AlexLehm> an example request via a proxy running on my local machine looks like this: https://gist.github.com/alexlehm/71877350886388a1fe5d0cc4c877352e

[23:33:48] <temporal_> I think it does not make sense configuration wise

[23:34:01] <temporal_> because then setSsl for ProxyType.SOCKS ?

[23:34:47] <AlexLehm> that is allowed

[23:35:22] <AlexLehm> SOCKS is tunnel protocol for any tcp connection, so setSsl with SOCKS can connect to port 443 and do the ssl protocol

[23:35:54] <AlexLehm> btw, there is a Proxy.Type enum in java as well https://docs.oracle.com/javase/7/docs/api/java/net/Proxy.Type.html

[23:36:00] <AlexLehm> that has HTTP and SOCKS (and none)

[23:36:11] <temporal_> ok

[23:36:24] <temporal_> ok

[23:36:42] <temporal_> so actually HttpClient will not do SSL and not SSL at the same time

[23:36:54] <temporal_> (but I knew that, wanted to check with getAbs)

[23:37:41] <temporal_> what I'm wondering is about the corner case

[23:37:52] <temporal_> there is only one

[23:38:10] <temporal_> using CONNECT without TLS

[23:38:24] <temporal_> but pehraps it does not make sense

[23:38:28] <temporal_> as you said

[23:39:04] <AlexLehm> this would be possible for NetClient, which makes sense for some things, but i think it doesn't make sense for http with CONNECT in the HttpClient

[23:40:27] <temporal_> however I just checked

[23:40:32] <temporal_> it's possible to do a proxy request

[23:40:48] <temporal_> but NetClient code is different I think in the setup

[23:41:01] <temporal_> and NetClient without CONNECT would not make sense

[23:41:11] <temporal_> because the proxy server interprets HTTP

[23:41:13] <AlexLehm> yes

[23:41:18] <temporal_> so right now

[23:41:25] <temporal_> if you do

[23:41:25] <temporal_> client.get(8080, “localhost”, “http://www.google.com”, resp → {

[23:41:29] <temporal_> it works as I suspected

[23:42:31] <temporal_> so to sum up

[23:42:42] <temporal_> we can keep ProxyType.HTTP

[23:42:50] <temporal_> in case of NetClient it is always CONNECT

[23:43:09] <temporal_> in case of HttpClient it should be CONNECT with ssl=true

[23:43:17] <temporal_> and without CONNECT with ssl=false

[23:43:38] <temporal_> and the behavior with ssl=false should be like doing client.get(8080, “localhost”, “http://www.google.com”, resp → {});

[23:46:01] <AlexLehm> yes, that is correct

[23:47:24] <temporal_> so we need to leave as is and create an issue for the later

[23:47:42] <temporal_> for 3.3.2

[23:48:28] <AlexLehm> yes, i think i would like to add a note that this does not work currently to the docu page now

[23:48:40] <temporal_> yes

[23:48:58] <temporal_> do you want to do it ?

[23:49:01] <AlexLehm> i think it only talks about https connections

[23:49:13] <AlexLehm> yes, give me 2 minutes

[23:51:00] <temporal_> ok

[23:52:01] <temporal_> one thing we should try to do too

[23:52:02] <temporal_> is

[23:52:38] <temporal_> nothing, forget it

[23:52:45] <temporal_> https://github.com/eclipse/vert.x/issues/1498

[23:58:08] <AlexLehm> i have sent a pr with the package-info.java

[23:58:43] <temporal_> thanks

[23:59:32] <temporal_> can you amend and use {@link ProxyType.HTTP} instead

[23:59:42] <temporal_> so it will use “HTTP” string in othe rlanguages

[23:59:54] <AlexLehm> ah ok