On Thu, 2014-05-22 at 08:43 -0400, Karl Wright wrote: > Hi Oleg, > > We *are* using POST - multipart post. And this apparently extends > HttpRequestWrapper. Which is why expect/continue is not working for us. >
Why? What for? Even if you are absolutely certain wrapping is necessary in this case why then not use HttpRequestWrapper#wrap instead of class extension? The constructor of this class even intentionally made private to discourage people from its extension. > If you have a better solution, please let me know what it is. > What shall I do about HTTPCLIENT-1510? API elegancy, which is subjective and contentious topic, aside it is clearly not a bug with HttpClient. Oleg > Karl > > > > On Thu, May 22, 2014 at 8:40 AM, Oleg Kalnichevski <[email protected]> wrote: > > > On Thu, 2014-05-22 at 08:27 -0400, Karl Wright 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? > > > > > > > Why is exactly instanceof bad or less flexible? It enables certain > > requests to provide optional behavior such as ability to enclose a > > request entity, which by the current official HTTP spec applies to POST > > and PUT _only_. > > > > So, what is better, round or green? > > > > Oleg > > > > > 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] > > > >> > > > >> > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
