Add RFC 10008 (QUERY Method) Support

[desiderantes]

Motivation:

In order to add RFC 10008 support elsewhere in vert.x, these are the basic blocs required to support the QUERY Method.

Conformance:

• You should have signed the Eclipse Contributor Agreement as explained in https://github.com/eclipse/vert.x/blob/master/CONTRIBUTING.md

• Please also make sure you adhere to the code style guidelines: https://github.com/vert-x3/wiki/wiki/Vert.x-code-style-guidelines

[vietj]

I think that the redirect support is not correct because on a redirect the client needs to buffer the entire payload and send it again on a redirection.

[vietj]

I believe that to implement this correctly we would need the extra following features for the redirection

1. on a QUERY with redirect enabled, the HTTP client needs to buffer the query payload entirely
2. when the redirect handler responds a QUERY method with a non null request options, the buffered payload should be sent again

To make this more efficient, we should improve the client to make buffering efficient than it currently is, I am thinking of the HttpClientRequestImpl that should be optimized when we send a single buffer.

We would also need to make this buffering have an upper bound and take another path (e.g. avoid redirection) when the payload exceeds the max buffer size.

[vietj]

I think this is also relevant : https://github.com/netty/netty/pull/16978/changes

[desiderantes]

I believe that to implement this correctly we would need the extra following features for the redirection

1. on a QUERY with redirect enabled, the HTTP client needs to buffer the query payload entirely

2. when the redirect handler responds a QUERY method with a non null request options, the buffered payload should be sent again

Redirection in the RFC talks more about the client sending a QUERY and being redirected to do a GET (same or different endpoint). Redirecting a QUERY to another endpoint that handles QUERY would be the same as redirecting a PUT or a POST to another PUT/POST endpoint.

To make this more efficient, we should improve the client to make buffering efficient than it currently is, I am thinking of the HttpClientRequestImpl that should be optimized when we send a single buffer.

We would also need to make this buffering have an upper bound and take another path (e.g. avoid redirection) when the payload exceeds the max buffer size.

I think this is a further optimization that, based on the prior point, would be disconnected from QUERY support

[vietj]

I believe that to implement this correctly we would need the extra following features for the redirection

1. on a QUERY with redirect enabled, the HTTP client needs to buffer the query payload entirely

2. when the redirect handler responds a QUERY method with a non null request options, the buffered payload should be sent again

Redirection in the RFC talks more about the client sending a QUERY and being redirected to do a GET (same or different endpoint). Redirecting a QUERY to another endpoint that handles QUERY would be the same as redirecting a PUT or a POST to another PUT/POST endpoint.

as I read it, this is only valid for HTTP response status 303, the QUERY turns into a GET:

A response to QUERY with the status code 303 (See Other, Section 15.4.4 of [HTTP]) indicates that the original query can be accomplished via a normal retrieval request on the URI referenced by the Location response field ([HTTP], Section 10.2.2). For HTTP, this means sending a GET request to the new target URI, as illustrated by the example in Appendix A.4.3.

For other 4 status codes, I read:

In all four cases, the server is suggesting that the user agent can accomplish its original QUERY request by sending a similar QUERY request to the new target URI referenced by the Location.

To make this more efficient, we should improve the client to make buffering efficient than it currently is, I am thinking of the HttpClientRequestImpl that should be optimized when we send a single buffer.
We would also need to make this buffering have an upper bound and take another path (e.g. avoid redirection) when the payload exceeds the max buffer size.

I think this is a further optimization that, based on the prior point, would be disconnected from QUERY support

Right.

[desiderantes]

as I read it, this is only valid for HTTP response status 303, the QUERY turns into a GET:

A response to QUERY with the status code 303 (See Other, Section 15.4.4 of [HTTP]) indicates that the original query can be accomplished via a normal retrieval request on the URI referenced by the Location response field ([HTTP], Section 10.2.2). For HTTP, this means sending a GET request to the new target URI, as illustrated by the example in Appendix A.4.3.

For other 4 status codes, I read:

In all four cases, the server is suggesting that the user agent can accomplish its original QUERY request by sending a similar QUERY request to the new target URI referenced by the Location.

Yeah, I see what you mean, sorry. I'll drop the part related to this, and just have the test for redirection to GET. Then I'll take a look at making the QUERY resend possible

[vietj]

a few comments.

We also need to test the behavior when the buffered payload exceeds the max payload length (check we don't get a redirect I think and the reply is processed as is)