Mailing-List: contact httpclient-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient Project" <httpclient-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: 
 <OF46B83C26.5D948D4F-ONC1256FA0.00462D42-C1256FA0.00477990@de.ibm.com>
References: 
 <OF46B83C26.5D948D4F-ONC1256FA0.00462D42-C1256FA0.00477990@de.ibm.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3cc86e2429168ae88884f3f1aa2c1ef5@u.washington.edu>
Content-Transfer-Encoding: 7bit
From: Michael Becke <becke@u.washington.edu>
Subject: Re: HLCA: generating followup requests
Date: Sun, 6 Feb 2005 14:26:15 -0500
To: "HttpClient Project" <httpclient-dev@jakarta.apache.org>

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.

Mike

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