Client responses of HTTP conversations have mismatching request

[sbordet]

Jetty version(s)
12.1.x

Description
Following up on this comment: #1445 (comment)

In case of HTTP conversations, for example redirects, request Rq1 gets a 302 Rs1, which triggers the internal HttpClient mechanism to follow the redirect and send request Rq2 that gets a 200 Rs2.

Rs1 and Rq2 are "internal" and what the application sees is Rq1 and Rs2, i.e. the request and the 200 response.

Unfortunately, calling Response.getRequest() from listeners when Rs2 is notified to listeners attached to Rq1 via e.g. Request.onResponseSuccess(), yields Rq2 instead of Rq1.

[sbordet]

One other option is a new listener like that:

httpClient.newRequest(...)
    .onConversation((prevResponse, nextRequest) -> ...)
    .onComplete(response -> response.getRequest() == <the last request, not the previous, not the first>)

@lorban thoughts?

[lorban]

I don't like it, at least if we're looking for an answer to the original remark:

It turns out that onComplete is invoked with a Result whose embedded Request object is not equal to the Request object that initiated the request (the URL and HTTP method are the same but the Request object is not). This means my code has no way of knowing that a previously-fired request has actually completed.

In my view, making the onComplete() call with a response that links to the original request is a nice quality of life improvement that allows writing this kind of code:

httpClient.newRequest(...)
    .onComplete(response -> { Request r = response.getRequest(); makeUseOf(r); })

but you could still access the original request from onComplete by making the request code a bit uglier:

Request r = httpClient.newRequest(...);
r.onComplete(response -> { makeUseOf(r); })

I fail to see what onConversation() would solve as you'd still need to complexify your code to access the original request and doesn't really bring anything useful in this context.