Sangjin Lee wrote: <snip>
> That sounds like a good approach. Still some necessary normalization (like > something I see in DefaultHttpRequest.normalize()) would need to happen in > both cases, no? normalize() is defined in the MutableHttpRequest interface so in the case of a mutable request we would definitely have to normalize it. In the case of a non-mutable request (currently we don't have an HttpRequest that doesn't also implement MutableHttpRequest), we'll have to assume the request is already "normalized." <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. -Mike
