I've created HTTPCLIENT-1510 to summarize the problem and propose the outlines of a solution. Karl
On Thu, May 22, 2014 at 8:27 AM, Karl Wright <[email protected]> wrote: > Let me clarify. Right now, you've a wrapper hierarchy that is totally > distinct from the original request hierarchy. You *could* allow everything > wrapped with HttpRequestWrapper to allow expect/continue, in which case you > lose the ability to have specificity for different kinds of wrapped > requests. Or (much better) you could have all HttpRequest objects have a > "supportExpectContinue" method, which in the wrapper would wind up calling > the embedded request's supportExpectContinue method. Seems much better, no? > > Karl > > > On Thu, May 22, 2014 at 8:23 AM, Karl Wright <[email protected]> wrote: > >> >>>>>> >> Are you sure about that? What would this method do for GET requests >> given than those requests are not even supposed to enclose an entity? >> <<<<<< >> >> It would return false for any request implementation that did not support >> expect-continue, of course. >> The advantage of this kind of structure is that it does not rely on the >> implicit instanceof operator, but rather an explicit method implementation, >> so it is clearer (and more flexible). >> >> Karl >> >> >> >> On Thu, May 22, 2014 at 8:19 AM, Oleg Kalnichevski <[email protected]>wrote: >> >>> On Thu, 2014-05-22 at 07:55 -0400, Karl Wright wrote: >>> > FWIW, a better way for this kind of thing to be done would be for the >>> > request object to have a method, e.g. "supportsExpectContinue()", that >>> you >>> > would call, instead of relying on class names and hierarchy ... >>> > >>> >>> Are you sure about that? What would this method do for GET requests >>> given than those requests are not even supposed to enclose an entity? >>> >>> Oleg >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >
