WEBCLIENT do not encode URL fully (according to RFC 3986, only query parameters about vertx-web HOT 9 CLOSED

With UriTemplate you can get an absolute URI that is properly encoded:

String absoluteURI = UriTemplate.of("{scheme}://{host}:{port}/{path}")
      .expandToString(Variables.variables()
        .set("scheme", "http")
        .set("host", "127.0.0.1")
        .set("port", 8881)
        .set("path", "привет"));

But on the server side encoded path segments are not supported anyway. Would you like to contribute this?

from vertx-web.

With UriTemplate you can get an absolute URI that is properly encoded:

      .expandToString(Variables.variables()
        .set("scheme", "http")
        .set("host", "127.0.0.1")
        .set("port", 8881)
        .set("path", "привет"));

But on the server side encoded path segments are not supported anyway. Would you like to contribute this?

that sounds like an interesting idea🤗

from vertx-web.

yeah that's what URI template are made for

from vertx-web.

yeah that's what URI template are made for

can I really give it a try to implement decoding path segments at the server side ?

from vertx-web.

I'm not sure what you want to do since we are talking here about web client and not server

from vertx-web.

ah you mean Thomas suggestion

from vertx-web.

ah you mean Thomas suggestion

yeah, honestly i thought about server support from the start, because if webclient does not encode, why should the server have logic for decoding (cause it all in one ecosystem) ?
and now sounds interesting, maybe i could find the "path segments" resolving logic on server side and try out to implement decoding

from vertx-web.

and by webclient side i am not sure that it should be implemented, because I think that on client side that's not a problem in any case if we have UriTemplate or UrlEncoder

from vertx-web.

sure, I'll close this issue in the meantime then

from vertx-web.