hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Shubin <seanshu...@gmail.com>
Subject Re: I get SSLPeerUnverifiedException after upgrading from 4.3.6 to 4.4
Date Sun, 08 Feb 2015 22:14:33 GMT
I get the advantages of SLL, but publicsuffix is above and beyond SSL, and
is also not built in to browsers, so that does not address my central
question of:
"Why should an http client library be unable to execute an HTTP GET to a
location that any web browser can?"

What I perceived as a problem was that we have an http client library
applying different rules than http browsers.  Then again, perhaps all
of the browsers are wrong in this regard, and have not gotten around to
integrating the publicsuffix rules.

I don't really want to debate what the apache http client library should
do, I am more interested in understanding the priorities, so I can decide
if it is suited to my needs.

Should an http client library be a simple abstraction over HTTP?  In this
case it is really easy to automate anything a browser can do, but you don't
get the additional security of enforcing the publicsuffix rules.
Or should the http client library be smart enough to enforce rules that
browsers do not?  In this case the publicsuffix rules are enforced for
free, but since the behavior is different than that of http browsers, you
won't be able reliably automate http browsers.

On Sun, Feb 8, 2015 at 3:45 AM, Oleg Kalnichevski <olegk@apache.org> wrote:

> On Fri, 2015-02-06 at 13:21 -0800, Sean Shubin wrote:
> > Thanks for the information, I looked over publicsuffix.org.
> >
> > I am still not following the connection between an alternative subject
> name
> > being "too broad", and an http client failing to execute an HTTP GET
> > request.  What is the advantage?
> What is the advantage of SSL hostname verification or SSL security in
> general?
> Oleg
> >  Why should an http client library be
> > unable to execute an HTTP GET to a location that any web browser can?
> >
> > On Fri, Feb 6, 2015 at 2:03 AM, Oleg Kalnichevski <olegk@apache.org>
> wrote:
> >
> > > This makes 'githubusercontent.com' a public name space like 'com'
> > >  or 'co.uk'. Based on that HC 4.4 cannot accept
> > > '*.githubusercontent.com' alternative subject name as being too broad.
> > > For details see
> > > https://publicsuffix.org/
> > >
> > > Oleg
> > >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message