commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Lubke <Ryan.Lu...@Sun.COM>
Subject Re: [HttpClient] Thoughts on RFE 10790
Date Tue, 03 Sep 2002 02:10:38 GMT
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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message