hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: HLCA: generating followup requests
Date Sun, 06 Feb 2005 19:26:15 GMT
The request context is a good idea.  In combination with the filters I 
think this would be enough to handle authentication.  As Roland 
mentioned a filter should only need the current state and request URI 
to determine what to do.  We would just need a way to signal that 
request should be retried.  Would there be other uses for context other 
than authentication?

In regard to redirects I'm not sure there is a way to handle this 
entirely with filters.  The big problem here would be handling 
redirects in response to a POST, not only would we need to rewrite the 
request URI, but we need a new method type.


On Feb 6, 2005, at 8:01 AM, Roland Weber wrote:

> Hi Oleg,
>> We may think of an additional
>> abstraction layer in a form of HttpContext, which would enable the
>> redirect handler to reset the authentication process without being
>> directly coupled with any of the authentication classes.
> I like the idea of a context. I assume we will have an HttpAuthFilter
> responsible for inserting Authorization and Proxy-Authorization headers
> into requests, and an AuthenticationChallengeHandler in whatever form,
> which provides the authentication data for the filter. A context would
> be a good way for these two associated objects to share data. It is
> also a good way to share data across requests, like authentication
> challenges.
> To avoid bringing actual authentication dependencies into http-common,
> an approach similar to {s|g}etAttribute in the Servlet API could be
> taken. The context information from the original request can be made
> available in the associated responses and followup requests. This
> would make the context useful for applications as well.
> I still think that an authentication handler should itself detect
> state changes due to changing URLs, rather than rely on an explicit
> reset by a redirect handler. Like in a browser, the authentication
> state should keep track of the current authentication realms from
> which challenges have already been received, and the URL domains to
> which these realms extend.
> cheers,
>   Roland

To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

View raw message