[
https://issues.apache.org/jira/browse/HTTPCLIENT-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCLIENT-1607.
-------------------------------------------
Resolution: Won't Fix
Fix Version/s: (was: 5.0)
Hi Marcos
The AuthScheme API has changed considerably in the trunk (5.0). AuthScheme no
longer interacts directly with HTTP headers. This, for one, makes it
unnecessary for AuthScheme implementations to worry about whether they are
being used for target or proxy authorization. AuthSchemes now deal exclusively
with challenge / response tokens. As a result making AuthSchemere return
multiple response headers has become difficult. I am reluctant to introduce an
unnecessary layer of complexity to AuthScheme without a very convincing reason.
Oleg
> Change ContextAwareAuthScheme.authenticate to return a HeaderGroup instead of
> a single Header
> ---------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1607
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1607
> Project: HttpComponents HttpClient
> Issue Type: Wish
> Components: HttpClient
> Affects Versions: 4.3.6
> Reporter: Marcos Scriven
> Priority: Minor
>
> While writing a custom {{AuthScheme}}, I needed to add multiple headers to
> the request.
> This is of course possible just by directly adding them to the request
> available as a parameter, but then it makes the return value rather
> arbitrary. Returning null seems to work, and is just silently ignored.
> I think it would be more intuitive to change the interface to return a
> {{HeaderGroup}} instead.
> I guess an alternative would be to write a custom filter somewhere, but that
> wouldn't tie in nicely with authentication caches and user credentials
> automatically being applied according to the host route.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
