On Mon, 2011-11-07 at 19:33 +0000, sebb AT ASF wrote: > On 7 November 2011 19:28, Ryan J Baxter <rjbax...@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: rjbax...@us.ibm.com > > Phone: 978-899-3041 > > developerWorks Profile > > > > > > > > From: sebb AT ASF <s...@apache.org> > > To: Ryan J Baxter/Westford/IBM@Lotus, > > Cc: dev@shindig.apache.org, HttpComponents Project > > <d...@hc.apache.org> > > Date: 11/07/2011 02:19 PM > > Subject: Re: httpclient version upgrade causing SSL exceptions > > Sent by: seb...@gmail.com > > ________________________________ > > > > > > On 7 November 2011 18:45, Ryan J Baxter <rjbax...@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: rjbax...@us.ibm.com > >> Phone: 978-899-3041 > >> developerWorks Profile > >> > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org >