Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 92926 invoked from network); 3 Sep 2002 02:15:26 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Sep 2002 02:15:26 -0000 Received: (qmail 21314 invoked by uid 97); 3 Sep 2002 02:16:05 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 21254 invoked by uid 97); 3 Sep 2002 02:16:04 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 21242 invoked by uid 98); 3 Sep 2002 02:16:04 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Subject: Re: [HttpClient] Thoughts on RFE 10790 From: Ryan Lubke To: Jakarta Commons Developers List In-Reply-To: <3D7419C3.38F513E1@sympatico.ca> References: <1031017863.1595.43.camel@rivendell> <3D7419C3.38F513E1@sympatico.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 02 Sep 2002 22:10:38 -0400 Message-Id: <1031019039.1502.49.camel@rivendell> Mime-Version: 1.0 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Mon, 2002-09-02 at 22:09, Jeff Dever wrote: > I've spent some time considering this too. The digester/xml or betwixt setup > would be interesting, but first we should consider simpler solutions, such as > java.util.properties. Good enough. > > BTW: the bug is targeted for a 2.1 release. Unless there is a compelling reason > for having this in 2.0, this discussion should really be postponed untill we > release 2.0. Mostly because the Host header logic is bugging me. We need a way to make the behavior more inline with the behavior that commonly used user-agents use. I also think it would be good to have this level of control for 2.0, but that's just my opinion. I don't have any data on what other user's are doing as far as compliance configuration. If this is pushed back to 2.1, I think the current Host header logic should be relaxed until this is addressed (i.e. Send a non-empty host header not matter what is used to identify the target resource). > > > Ryan Lubke wrote: > > > I'd like to get a discussion going on how best to tackle > > the RFE described by 10790 > > > > - http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10790 > > > > The RFE basically requests that instead of having a global flag > > to make an entire request compliant or not, that it would be desirable > > to make each existing behavior currently affected by this flag > > configurable independent of each other. > > > > So one thought I had was the possibility of a ConfigurationContext > > implemented as a Singleton. The user can configure the > > ConfigurationContext via an XML configuration file and possibly use > > Digester to parse the XML and provide the initial values to the > > ConfigurationContext. The users can access the ConfigurationContext via > > a factory method where once they have the instance, they can use setters > > and getters to access specific properties at runtime. > > > > HttpMethodBase would then interrogate the ConfigurationContext for its > > behavior path during execution. > > > > I guess this could be taken further and have a ConfigurationContext for > > each type of Method (i.e. a context for GetMethods, a context for > > PostMethods, etc). This would provide a finer granularity of control. > > > > I've got a proof of concept in the works, but would appreciate feedback > > on if this is going in a good direction or if there is a better > > alternative someone has been kicking around but hasn't been able to > > implement. > > > > Thoughts? Comments? > > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > -- To unsubscribe, e-mail: For additional commands, e-mail: