Return-Path: X-Original-To: apmail-manifoldcf-dev-archive@www.apache.org Delivered-To: apmail-manifoldcf-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 452091128C for ; Thu, 22 May 2014 12:42:07 +0000 (UTC) Received: (qmail 87449 invoked by uid 500); 22 May 2014 12:42:07 -0000 Delivered-To: apmail-manifoldcf-dev-archive@manifoldcf.apache.org Received: (qmail 87405 invoked by uid 500); 22 May 2014 12:42:07 -0000 Mailing-List: contact dev-help@manifoldcf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@manifoldcf.apache.org Delivered-To: mailing list dev@manifoldcf.apache.org Delivered-To: moderator for dev@manifoldcf.apache.org Received: (qmail 83878 invoked by uid 99); 22 May 2014 12:40:32 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Message-ID: <1400762402.22454.7.camel@ubuntu> Subject: Re: Expect-continue doesn't seem operative using 4.3.x builder structures From: Oleg Kalnichevski To: HttpComponents Project Cc: dev Date: Thu, 22 May 2014 14:40:02 +0200 In-Reply-To: References: <1400678661.5757.3.camel@ubuntu> <1400682231.7338.2.camel@ubuntu> <1400761166.20033.8.camel@ubuntu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 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 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: dev-unsubscribe@hc.apache.org > >> For additional commands, e-mail: dev-help@hc.apache.org > >> > >> > >