Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Mon, 8 Feb 2016 17:28:40 +0000 (UTC)
From: =?utf-8?Q?Tom=C3=A1=C5=A1_Zilvar_=28JIRA=29?= <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12690154.1390350983000.329999.1454952520355@Atlassian.JIRA>
In-Reply-To: <JIRA.12690154.1390350983000@Atlassian.JIRA>
References: <JIRA.12690154.1390350983000@Atlassian.JIRA>
 <JIRA.12690154.1390350983894@arcas>
Subject: [jira] [Commented] (HTTPCLIENT-1451) HttpClient does not store
 response cookies on a 401
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1451?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15137287#comment-15137287 ]=20

Tom=C3=A1=C5=A1 Zilvar commented on HTTPCLIENT-1451:
------------------------------------------

[~olegk] it seems to me that stating the behavior proposed by the reporter =
would be _non-standard_ is at least debatable, if not simply not true. Whil=
e we can agree that the client MAY ignore the {{Set-Cookie}} header entirel=
y, there is no reason that it should do so under these circumstances. There=
 is no requirement to repeat the request with no changes whatsoever (other =
than adding Authorization header).

In fact the situation regarding standards in this case is quite the opposit=
e I would say, because when you do not run the whole chain again, you are n=
ot just discarding cookies from the 401 response, but you are also in dange=
r of sending expired cookies in the subsequent request (the whole charade c=
ould take quite some time) when you just blindly send the same one again ap=
pending an Authorization header, thus breaking RFC 6265 requirement:

{quote}
A cookie is "expired" if the cookie has an expiry date in the past.

The user agent MUST evict all expired cookies from the cookie store
if, at any time, an expired cookie exists in the cookie store.
{quote}

Last, but not least, this behavior was introduced in HttpClient 4, as oppos=
ed to HttpClient 3 which did respect a {{Set-Cookie}} header in the 401 aut=
hentication challenge.

> HttpClient does not store response cookies on a 401
> ---------------------------------------------------
>
>                 Key: HTTPCLIENT-1451
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-145=
1
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpAuth
>    Affects Versions: 4.3.2
>            Reporter: Richard Sand
>            Priority: Minor
>             Fix For: 5.0
>
>
> Using HttpClient 4.3.2 to call a Web Service which is secured with BASIC =
authentication. The server responds to the initial request with a 401 respo=
nse but also includes a cookie.
> The HttpClient does not place response cookies into the cookie store unti=
l after it has completed the subsequent request with the Authorize header, =
but the server rejects the authentication if the cookie is missing.=20
> To work around this I had to disable the authentication capability in the=
 HttpClientContext and manually check for the 401 response code, and then s=
end a followup request with a manually set Authorize header.
> So in the use case where the HttpClient is automatically sending a follow=
up request with credentials in response to a 401, the client should place t=
he cookies from the original response into the cookie store immediately, ra=
ther than waiting for after the response to the credentials (the 2nd respon=
se).


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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