hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Lindner <lind...@inuus.com>
Subject Re: httpclient version upgrade causing SSL exceptions
Date Mon, 07 Nov 2011 21:17:43 GMT
I had a patch to use the non-deprecated methods in shindig.  It caused
problems for containers that had not already upgraded so I reverted it.  I
can bring it back pretty easily.


On Mon, Nov 7, 2011 at 11:56 AM, Oleg Kalnichevski <olegk@apache.org> wrote:

> On Mon, 2011-11-07 at 19:33 +0000, sebb AT ASF wrote:
> > On 7 November 2011 19:28, Ryan J Baxter <rjbaxter@us.ibm.com> wrote:
> > > Thanks Sebastian.
> > >
> > > I am not to familiar with this part of the code in Shindig but it
> looks like
> > > we are just passing the host name, ie https://ajax.googleapis.com, to
> the
> > > fetcher.
> >
> > Yes, I suspect the /IP part is being generated internally by HC 4.1.2.
> >
> > > Is there anything we as the the Shindig community can do to help
> > > out?
> >
> > If it's easy to test with 4.2-alpha1, it would help to know if that is
> > also affected.
> >
> > > -Ryan
> > >
>
> Folks
>
> This issue has been beaten to death on a number of occasions. The bug
> affects deprecated functionality only and it has already been fixed in
> the 4.2 branch.
>
> To fix the problem regardless of the release version just make sure to
> not use deprecated methods of the Scheme class.
>
> Hope this helps
>
> Oleg
>
>
> > > Email: rjbaxter@us.ibm.com
> > > Phone: 978-899-3041
> > > developerWorks Profile
> > >
> > >
> > >
> > > From:        sebb AT ASF <sebb@apache.org>
> > > To:        Ryan J Baxter/Westford/IBM@Lotus,
> > > Cc:        dev@shindig.apache.org, HttpComponents Project
> > > <dev@hc.apache.org>
> > > Date:        11/07/2011 02:19 PM
> > > Subject:        Re: httpclient version upgrade causing SSL exceptions
> > > Sent by:        sebbaz@gmail.com
> > > ________________________________
> > >
> > >
> > > On 7 November 2011 18:45, Ryan J Baxter <rjbaxter@us.ibm.com> wrote:
> > >> I have been seeing SSL exceptions being thrown relating to
> certificates
> > >> not
> > >> matching in builds from trunk recently.  I have traced this back to a
> > >> httpclient upgrade from 4.1.1 to 4.1.2.  Would anyone be opposed to
> > >> reverting back to 4.1.1 for the time being?
> > >>
> > >> Looking that the changes that went into 4.1.2, this change looks like
> it
> > >> might be related to the problem.  I have CCed Sebastian, maybe he can
> > >> confirm.
> > >
> > > This should really have been fed back to all the HttpComponents
> > > developers via e-mail or JIRA issue; I'm copying the mailing on this
> > > reply.
> > >
> > >>
> > >> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and
> > >> StrictHostnameVerifier
> > >> should handle
> > >>  wildcards in SSL certificates better.
> > >>  Contributed by Sebastian Bazley <sebb at apache.org>
> > >
> > >> INFO: The following exception occurred when fetching
> > >>
> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405ms
> > >> elapsed.
> > >> Nov 7, 2011 1:38:28 PM
> org.apache.shindig.gadgets.http.BasicHttpFetcher
> > >> fetch
> > >> INFO:
> > >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> > >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> > >> <googleapis.com> OR <*.googleapis.com>
> > >>         at
> > >
> > > It's not obvious why the hostname includes an IP address as well as a
> name.
> > > I don't yet know if the validation is supposed to cope with that or
> not.
> > >
> > > Also rather odd is that the hostname and IP address do not agree.
> > >
> > > It's quite possible that the validation is wrong, and it should allow
> > > for the /IP suffix, but it's also possible that the wrong hostname is
> > > being passed to the validation method.
> > >
> > >>
> > >>
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
> > >>         at
> > >>
> > >>
> org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
> > >>         at
> > >>
> > >>
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
> > >>         at
> > >>
> > >>
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
> > >>         at
> > >>
> > >>
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
> > >>         at
> > >>
> > >>
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
> > >>         at
> > >>
> > >>
> org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
> > >>         at
> > >>
> > >>
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
> > >>         at
> > >>
> > >>
> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
> > >>         at
> > >>
> > >>
> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
> > >>         at
> > >>
> > >>
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
> > >>         at
> > >>
> > >>
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
> > >>         at
> > >>
> > >>
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
> > >>         at
> > >>
> > >>
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
> > >>         at
> > >>
> > >>
> org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
> > >>         at
> > >>
> > >>
> org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
> > >>         at
> > >>
> > >>
> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
> > >>         at
> > >>
> > >>
> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
> > >>         at
> > >> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> > >>         at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> > >>         at
> > >>
> > >>
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> > >>         at
> > >>
> > >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> > >>         at java.lang.Thread.run(Thread.java:662)
> > >> Nov 7, 2011 1:38:28 PM
> > >> org.apache.shindig.gadgets.servlet.ConcatProxyServlet
> > >> outputError
> > >> INFO: The following error occurred when requesting a concatenated
> proxy:
> > >> /*
> > >> ---- Error INTERNAL_SERVER_ERROR
> > >> concat(
> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
> > >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> > >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> > >> <googleapis.com> OR <*.googleapis.com> ---- */.
> > >>
> > >> -Ryan
> > >>
> > >> Email: rjbaxter@us.ibm.com
> > >> Phone: 978-899-3041
> > >> developerWorks Profile
> > >>
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
>
>


-- 
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner

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