You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ryan Lubke <Ry...@Sun.COM> on 2002/09/03 03:51:02 UTC
[HttpClient] Thoughts on RFE 10790
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?
-rl
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [HttpClient] Thoughts on RFE 10790
Posted by Ryan Lubke <Ry...@Sun.COM>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [HttpClient] Thoughts on RFE 10790
Posted by Jeff Dever <js...@sympatico.ca>.
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.
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.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>