Mike Heath wrote:
<snip>
I think in general some amount of knowledge about the request is unavoidable
on the response. If the response object has no knowledge of what the
request was, there will be certain things that are not possible to do.
There may be many examples, but one example I can think of is inspecting
the Set-Cookie header to accept or reject cookies. Things like domain and
path validation are needed but that requires the request. AHC's
HttpResponseMessage also does not know about the request, and it's been a
pain point.
I agree. I've added an HttpRequestFuture that extends HttpFuture in my
proposed API. The HttpRequestFuture has a getHttpRequest() method on
it. I'm adding a few other tweaks and then I'll republish my proposed API.
Keeping the request around may be expensive, consider POSTs with a large
body for example. However, I think that having the other information
available in the response would be a good idea. However, it's not
strictly necessary as that information (or the request itself, even) can
be passed to the Listener directly, if a new listener is created for
each request.
