You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Bronislav Gabrhelik <di...@ahojky.com> on 2013/01/06 23:17:34 UTC

The digest authentication doesn't work when using proxy

Hello,

I came across the following issue. If I configure the HttpClient with
proxy(no-auth) then the digest authentication is failed by the server with
400 Bad request. After short analysis I have found out that the digest
authentication request contains an absolute URI instead of a relative
URI.The absolute URI is set in the DefaultRequestDirector.execute() by
calling of DefaultRequestDirector.rewriteRequestURI() in case the proxy is
configured. The parsed log from netmon is in the attachment.

Originally I have found the problem with my own Digest Authentication
Scheme (using Windows SSPI). After that I tried the build-in Digest auth
scheme and I was able to reproduce the issue. I noticed that the request
arg in the Schema.Authenticate is RequestWrapper, so i tried to use
RequestWrapper.getOriginal() for retrieving of URI, but I had n o success.
It returns also an absolute URI.

I believe it is a bug in the HttpClient. Besides that I would like to
address this problem in our DigestAuthScheme before it will be fixed in the
HttpClient. Is there some consistent way how how to get relative URI from
the HttpRequest or HttpContext passed into authenticate() method? I know I
can use the URI class to get a relative path, but it seems just like a
workaround.

Environment:
  JRE 1.6.0_23, Windows 7 SP1
dependencies:
  commons-codec-1.6.jar
  commons-logging-1.1.1.jar
  fluent-hc-4.2.2.jar
  httpclient-4.2.2.jar
  httpclient-cache-4.2.2.jar
  httpcore-4.2.3.jar
  httpmime-4.2.2.jar

Thanks,
Bronislav Gabrhelik

Re: The digest authentication doesn't work when using proxy

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2013-01-07 at 15:00 +0100, Bronislav Gabrhelik wrote:
> Oleg,
> 
> thanks for pointing this out.  I have realized that it is my fault after
> that I verified that the proxy is transparent.
> 
> The problem is missing slash at the end of URI while constructing the
> HttpGet().
> 
> "http://auth-digest2.brno.local"
> vs.
> "http://auth-digest2.brno.local/"
> 
> The question is if user shouldn't be forced to use the ending slash in all
> cases even if proxy is not used. I understand that HttpClient tries to be
> tolerant, but the use of API would be more consistent.
> 
> Thanks for your help,
> Bronislav
> 

Yes, the ending slash should be enforced. If it is not the case, this is
definitely a bug. Please raise a JIRA for this defect.

Oleg 

> 
> 
> 2013/1/7 Oleg Kalnichevski <ol...@apache.org>
> 
> > On Sun, 2013-01-06 at 23:17 +0100, Bronislav Gabrhelik wrote:
> > > Hello,
> > >
> > >
> > > I came across the following issue. If I configure the HttpClient with
> > > proxy(no-auth) then the digest authentication is failed by the server
> > > with 400 Bad request. After short analysis I have found out that the
> > > digest authentication request contains an absolute URI instead of a
> > > relative URI.The absolute URI is set in the
> > > DefaultRequestDirector.execute() by calling
> > > of DefaultRequestDirector.rewriteRequestURI() in case the proxy is
> > > configured. The parsed log from netmon is in the attachment.
> > >
> > >
> > > Originally I have found the problem with my own Digest Authentication
> > > Scheme (using Windows SSPI). After that I tried the build-in Digest
> > > auth scheme and I was able to reproduce the issue. I noticed that the
> > > request arg in the Schema.Authenticate is RequestWrapper, so i tried
> > > to use RequestWrapper.getOriginal() for retrieving of URI, but I had n
> > > o success. It returns also an absolute URI.
> > >
> > >
> > > I believe it is a bug in the HttpClient. Besides that I would like to
> > > address this problem in our DigestAuthScheme before it will be fixed
> > > in the HttpClient.
> >
> > Bronislav
> >
> > Similar issue was reported in the past. I think HttpClient's behavior is
> > correct and is compliant with the requirements of the HTTP
> > specification. The problem is on the proxy side. For details please see:
> >
> > https://issues.apache.org/jira/browse/HTTPCLIENT-1071
> >
> > Feel free to report this problem to developers of the proxy server.
> >
> > Oleg
> >
> >
> >
> > >  Is there some consistent way how how to get relative URI from the
> > > HttpRequest or HttpContext passed into authenticate() method? I know I
> > > can use the URI class to get a relative path, but it seems just like a
> > > workaround.
> > >
> > >
> > > Environment:
> > >   JRE 1.6.0_23, Windows 7 SP1
> > > dependencies:
> > >   commons-codec-1.6.jar
> > >   commons-logging-1.1.1.jar
> > >   fluent-hc-4.2.2.jar
> > >   httpclient-4.2.2.jar
> > >   httpclient-cache-4.2.2.jar
> > >   httpcore-4.2.3.jar
> > >   httpmime-4.2.2.jar
> > >
> > >
> > > Thanks,
> > > Bronislav Gabrhelik
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >



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


Re: The digest authentication doesn't work when using proxy

Posted by Bronislav Gabrhelik <di...@ahojky.com>.
Oleg,

thanks for pointing this out.  I have realized that it is my fault after
that I verified that the proxy is transparent.

The problem is missing slash at the end of URI while constructing the
HttpGet().

"http://auth-digest2.brno.local"
vs.
"http://auth-digest2.brno.local/"

The question is if user shouldn't be forced to use the ending slash in all
cases even if proxy is not used. I understand that HttpClient tries to be
tolerant, but the use of API would be more consistent.

Thanks for your help,
Bronislav



2013/1/7 Oleg Kalnichevski <ol...@apache.org>

> On Sun, 2013-01-06 at 23:17 +0100, Bronislav Gabrhelik wrote:
> > Hello,
> >
> >
> > I came across the following issue. If I configure the HttpClient with
> > proxy(no-auth) then the digest authentication is failed by the server
> > with 400 Bad request. After short analysis I have found out that the
> > digest authentication request contains an absolute URI instead of a
> > relative URI.The absolute URI is set in the
> > DefaultRequestDirector.execute() by calling
> > of DefaultRequestDirector.rewriteRequestURI() in case the proxy is
> > configured. The parsed log from netmon is in the attachment.
> >
> >
> > Originally I have found the problem with my own Digest Authentication
> > Scheme (using Windows SSPI). After that I tried the build-in Digest
> > auth scheme and I was able to reproduce the issue. I noticed that the
> > request arg in the Schema.Authenticate is RequestWrapper, so i tried
> > to use RequestWrapper.getOriginal() for retrieving of URI, but I had n
> > o success. It returns also an absolute URI.
> >
> >
> > I believe it is a bug in the HttpClient. Besides that I would like to
> > address this problem in our DigestAuthScheme before it will be fixed
> > in the HttpClient.
>
> Bronislav
>
> Similar issue was reported in the past. I think HttpClient's behavior is
> correct and is compliant with the requirements of the HTTP
> specification. The problem is on the proxy side. For details please see:
>
> https://issues.apache.org/jira/browse/HTTPCLIENT-1071
>
> Feel free to report this problem to developers of the proxy server.
>
> Oleg
>
>
>
> >  Is there some consistent way how how to get relative URI from the
> > HttpRequest or HttpContext passed into authenticate() method? I know I
> > can use the URI class to get a relative path, but it seems just like a
> > workaround.
> >
> >
> > Environment:
> >   JRE 1.6.0_23, Windows 7 SP1
> > dependencies:
> >   commons-codec-1.6.jar
> >   commons-logging-1.1.1.jar
> >   fluent-hc-4.2.2.jar
> >   httpclient-4.2.2.jar
> >   httpclient-cache-4.2.2.jar
> >   httpcore-4.2.3.jar
> >   httpmime-4.2.2.jar
> >
> >
> > Thanks,
> > Bronislav Gabrhelik
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>

Re: The digest authentication doesn't work when using proxy

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2013-01-06 at 23:17 +0100, Bronislav Gabrhelik wrote:
> Hello,
> 
> 
> I came across the following issue. If I configure the HttpClient with
> proxy(no-auth) then the digest authentication is failed by the server
> with 400 Bad request. After short analysis I have found out that the
> digest authentication request contains an absolute URI instead of a
> relative URI.The absolute URI is set in the
> DefaultRequestDirector.execute() by calling
> of DefaultRequestDirector.rewriteRequestURI() in case the proxy is
> configured. The parsed log from netmon is in the attachment.
> 
> 
> Originally I have found the problem with my own Digest Authentication
> Scheme (using Windows SSPI). After that I tried the build-in Digest
> auth scheme and I was able to reproduce the issue. I noticed that the
> request arg in the Schema.Authenticate is RequestWrapper, so i tried
> to use RequestWrapper.getOriginal() for retrieving of URI, but I had n
> o success. It returns also an absolute URI.
> 
> 
> I believe it is a bug in the HttpClient. Besides that I would like to
> address this problem in our DigestAuthScheme before it will be fixed
> in the HttpClient.

Bronislav

Similar issue was reported in the past. I think HttpClient's behavior is
correct and is compliant with the requirements of the HTTP
specification. The problem is on the proxy side. For details please see:

https://issues.apache.org/jira/browse/HTTPCLIENT-1071

Feel free to report this problem to developers of the proxy server.

Oleg



>  Is there some consistent way how how to get relative URI from the
> HttpRequest or HttpContext passed into authenticate() method? I know I
> can use the URI class to get a relative path, but it seems just like a
> workaround. 
> 
> 
> Environment:
>   JRE 1.6.0_23, Windows 7 SP1
> dependencies:
>   commons-codec-1.6.jar
>   commons-logging-1.1.1.jar
>   fluent-hc-4.2.2.jar
>   httpclient-4.2.2.jar
>   httpclient-cache-4.2.2.jar
>   httpcore-4.2.3.jar 
>   httpmime-4.2.2.jar
> 
> 
> Thanks,
> Bronislav Gabrhelik
>  
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org



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