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] >> >> >
