You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Ryan J Baxter <rj...@us.ibm.com> on 2011/11/07 19:45:31 UTC
httpclient version upgrade causing SSL exceptions
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.
* [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: 405 ms
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 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
Re: httpclient version upgrade causing SSL exceptions
Posted by Ryan J Baxter <rj...@us.ibm.com>.
+1
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Henry Saputra <he...@gmail.com>
To: dev@shindig.apache.org,
Date: 11/10/2011 03:18 PM
Subject: Re: httpclient version upgrade causing SSL exceptions
+1 for another beta release next week.
- Henry
On Thu, Nov 10, 2011 at 10:53 AM, Paul Lindner <li...@inuus.com> wrote:
> It's not too hard to spin off more betas at this point now that all the
> boilerplate and build issues were ironed out for beta3.
>
> Let's decide when the next cut should be. How about early next week?
That
> will give us time to get more code committed.
>
>
> On Thu, Nov 10, 2011 at 9:44 AM, Henry Saputra
<he...@gmail.com>wrote:
>
>> Yeah I think its not in the beta3 snapshots and since the release is
>> out we need to either deliver beta3-1 or wait for beta4
>>
>> - Henry
>>
>> On Thu, Nov 10, 2011 at 9:37 AM, daviesd <da...@oclc.org> wrote:
>> > I¹m seeing the same error. I assume this didn¹t make it into the
beta3
>> > snapshot? We try not to use trunk artifacts in our build process.
Am I
>> > gonna have to wait until another beta?
>> >
>> > Thanks,
>> > doug
>> >
>> >
>> > On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
>> >
>> >> Looks good so far Paul. I will do some more testing tomorrow.
>> >>
>> >> -Ryan
>> >>
>> >> Email: rjbaxter@us.ibm.com
>> >> Phone: 978-899-3041
>> >> developerWorks Profile
>> >>
>> >>
>> >>
>> >> From: Paul Lindner <li...@inuus.com>
>> >> To: dev@shindig.apache.org,
>> >> Cc: HttpComponents Project <de...@hc.apache.org>
>> >> Date: 11/07/2011 07:27 PM
>> >> Subject: Re: httpclient version upgrade causing SSL
exceptions
>> >>
>> >>
>> >>
>> >> I unreverted the changes and committed since this was already in the
>> >> codebase before.
>> >>
>> >> Let me know if it helps.
>> >>
>> >>
>> >
>> >
>>
>
>
>
> --
> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>
Re: httpclient version upgrade causing SSL exceptions
Posted by daviesd <da...@oclc.org>.
Any ideas if we'll get another beta before Thanksgiving?
Thanks,
doug
On 11/10/11 3:19 PM, "Henry Saputra" <he...@gmail.com> wrote:
> +1 for another beta release next week.
>
> - Henry
>
> On Thu, Nov 10, 2011 at 10:53 AM, Paul Lindner <li...@inuus.com> wrote:
>> It's not too hard to spin off more betas at this point now that all the
>> boilerplate and build issues were ironed out for beta3.
>>
>> Let's decide when the next cut should be. ?How about early next week? ?That
>> will give us time to get more code committed.
>>
>>
>> On Thu, Nov 10, 2011 at 9:44 AM, Henry Saputra
>> <he...@gmail.com>wrote:
>>
>>> Yeah I think its not in the beta3 snapshots and since the release is
>>> out we need to either deliver beta3-1 or wait for beta4
>>>
>>> - Henry
>>>
>>> On Thu, Nov 10, 2011 at 9:37 AM, daviesd <da...@oclc.org> wrote:
>>>> I¹m seeing the same error. ?I assume this didn¹t make it into the beta3
>>>> snapshot? ?We try not to use trunk artifacts in our build process. ?Am I
>>>> gonna have to wait until another beta?
>>>>
>>>> Thanks,
>>>> doug
>>>>
>>>>
>>>> On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
>>>>
>>>>> Looks good so far Paul. ?I will do some more testing tomorrow.
>>>>>
>>>>> -Ryan
>>>>>
>>>>> Email: rjbaxter@us.ibm.com
>>>>> Phone: 978-899-3041
>>>>> developerWorks Profile
>>>>>
>>>>>
>>>>>
>>>>> From: ? Paul Lindner <li...@inuus.com>
>>>>> To: ? ? dev@shindig.apache.org,
>>>>> Cc: ? ? HttpComponents Project <de...@hc.apache.org>
>>>>> Date: ? 11/07/2011 07:27 PM
>>>>> Subject: ? ? ? ?Re: httpclient version upgrade causing SSL exceptions
>>>>>
>>>>>
>>>>>
>>>>> I unreverted the changes and committed since this was already in the
>>>>> codebase before.
>>>>>
>>>>> Let me know if it helps.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>>
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Henry Saputra <he...@gmail.com>.
+1 for another beta release next week.
- Henry
On Thu, Nov 10, 2011 at 10:53 AM, Paul Lindner <li...@inuus.com> wrote:
> It's not too hard to spin off more betas at this point now that all the
> boilerplate and build issues were ironed out for beta3.
>
> Let's decide when the next cut should be. How about early next week? That
> will give us time to get more code committed.
>
>
> On Thu, Nov 10, 2011 at 9:44 AM, Henry Saputra <he...@gmail.com>wrote:
>
>> Yeah I think its not in the beta3 snapshots and since the release is
>> out we need to either deliver beta3-1 or wait for beta4
>>
>> - Henry
>>
>> On Thu, Nov 10, 2011 at 9:37 AM, daviesd <da...@oclc.org> wrote:
>> > I¹m seeing the same error. I assume this didn¹t make it into the beta3
>> > snapshot? We try not to use trunk artifacts in our build process. Am I
>> > gonna have to wait until another beta?
>> >
>> > Thanks,
>> > doug
>> >
>> >
>> > On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
>> >
>> >> Looks good so far Paul. I will do some more testing tomorrow.
>> >>
>> >> -Ryan
>> >>
>> >> Email: rjbaxter@us.ibm.com
>> >> Phone: 978-899-3041
>> >> developerWorks Profile
>> >>
>> >>
>> >>
>> >> From: Paul Lindner <li...@inuus.com>
>> >> To: dev@shindig.apache.org,
>> >> Cc: HttpComponents Project <de...@hc.apache.org>
>> >> Date: 11/07/2011 07:27 PM
>> >> Subject: Re: httpclient version upgrade causing SSL exceptions
>> >>
>> >>
>> >>
>> >> I unreverted the changes and committed since this was already in the
>> >> codebase before.
>> >>
>> >> Let me know if it helps.
>> >>
>> >>
>> >
>> >
>>
>
>
>
> --
> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>
Re: httpclient version upgrade causing SSL exceptions
Posted by daviesd <da...@oclc.org>.
Ya, another beta at a stable point would be great. Thanks.
doug
On 11/10/11 1:53 PM, "Paul Lindner" <li...@inuus.com> wrote:
> It's not too hard to spin off more betas at this point now that all the
> boilerplate and build issues were ironed out for beta3.
>
> Let's decide when the next cut should be. How about early next week? That
> will give us time to get more code committed.
>
>
> On Thu, Nov 10, 2011 at 9:44 AM, Henry Saputra <he...@gmail.com>wrote:
>
>> Yeah I think its not in the beta3 snapshots and since the release is
>> out we need to either deliver beta3-1 or wait for beta4
>>
>> - Henry
>>
>> On Thu, Nov 10, 2011 at 9:37 AM, daviesd <da...@oclc.org> wrote:
>>> I¹m seeing the same error. I assume this didn¹t make it into the beta3
>>> snapshot? We try not to use trunk artifacts in our build process. Am I
>>> gonna have to wait until another beta?
>>>
>>> Thanks,
>>> doug
>>>
>>>
>>> On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
>>>
>>>> Looks good so far Paul. I will do some more testing tomorrow.
>>>>
>>>> -Ryan
>>>>
>>>> Email: rjbaxter@us.ibm.com
>>>> Phone: 978-899-3041
>>>> developerWorks Profile
>>>>
>>>>
>>>>
>>>> From: Paul Lindner <li...@inuus.com>
>>>> To: dev@shindig.apache.org,
>>>> Cc: HttpComponents Project <de...@hc.apache.org>
>>>> Date: 11/07/2011 07:27 PM
>>>> Subject: Re: httpclient version upgrade causing SSL exceptions
>>>>
>>>>
>>>>
>>>> I unreverted the changes and committed since this was already in the
>>>> codebase before.
>>>>
>>>> Let me know if it helps.
>>>>
>>>>
>>>
>>>
>>
>
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Paul Lindner <li...@inuus.com>.
It's not too hard to spin off more betas at this point now that all the
boilerplate and build issues were ironed out for beta3.
Let's decide when the next cut should be. How about early next week? That
will give us time to get more code committed.
On Thu, Nov 10, 2011 at 9:44 AM, Henry Saputra <he...@gmail.com>wrote:
> Yeah I think its not in the beta3 snapshots and since the release is
> out we need to either deliver beta3-1 or wait for beta4
>
> - Henry
>
> On Thu, Nov 10, 2011 at 9:37 AM, daviesd <da...@oclc.org> wrote:
> > I¹m seeing the same error. I assume this didn¹t make it into the beta3
> > snapshot? We try not to use trunk artifacts in our build process. Am I
> > gonna have to wait until another beta?
> >
> > Thanks,
> > doug
> >
> >
> > On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
> >
> >> Looks good so far Paul. I will do some more testing tomorrow.
> >>
> >> -Ryan
> >>
> >> Email: rjbaxter@us.ibm.com
> >> Phone: 978-899-3041
> >> developerWorks Profile
> >>
> >>
> >>
> >> From: Paul Lindner <li...@inuus.com>
> >> To: dev@shindig.apache.org,
> >> Cc: HttpComponents Project <de...@hc.apache.org>
> >> Date: 11/07/2011 07:27 PM
> >> Subject: Re: httpclient version upgrade causing SSL exceptions
> >>
> >>
> >>
> >> I unreverted the changes and committed since this was already in the
> >> codebase before.
> >>
> >> Let me know if it helps.
> >>
> >>
> >
> >
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: httpclient version upgrade causing SSL exceptions
Posted by Henry Saputra <he...@gmail.com>.
Yeah I think its not in the beta3 snapshots and since the release is
out we need to either deliver beta3-1 or wait for beta4
- Henry
On Thu, Nov 10, 2011 at 9:37 AM, daviesd <da...@oclc.org> wrote:
> I¹m seeing the same error. I assume this didn¹t make it into the beta3
> snapshot? We try not to use trunk artifacts in our build process. Am I
> gonna have to wait until another beta?
>
> Thanks,
> doug
>
>
> On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
>
>> Looks good so far Paul. I will do some more testing tomorrow.
>>
>> -Ryan
>>
>> Email: rjbaxter@us.ibm.com
>> Phone: 978-899-3041
>> developerWorks Profile
>>
>>
>>
>> From: Paul Lindner <li...@inuus.com>
>> To: dev@shindig.apache.org,
>> Cc: HttpComponents Project <de...@hc.apache.org>
>> Date: 11/07/2011 07:27 PM
>> Subject: Re: httpclient version upgrade causing SSL exceptions
>>
>>
>>
>> I unreverted the changes and committed since this was already in the
>> codebase before.
>>
>> Let me know if it helps.
>>
>>
>
>
Re: httpclient version upgrade causing SSL exceptions
Posted by daviesd <da...@oclc.org>.
I¹m seeing the same error. I assume this didn¹t make it into the beta3
snapshot? We try not to use trunk artifacts in our build process. Am I
gonna have to wait until another beta?
Thanks,
doug
On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
> Looks good so far Paul. I will do some more testing tomorrow.
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Paul Lindner <li...@inuus.com>
> To: dev@shindig.apache.org,
> Cc: HttpComponents Project <de...@hc.apache.org>
> Date: 11/07/2011 07:27 PM
> Subject: Re: httpclient version upgrade causing SSL exceptions
>
>
>
> I unreverted the changes and committed since this was already in the
> codebase before.
>
> Let me know if it helps.
>
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Looks good so far Paul. I will do some more testing tomorrow.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Paul Lindner <li...@inuus.com>
To: dev@shindig.apache.org,
Cc: HttpComponents Project <de...@hc.apache.org>
Date: 11/07/2011 07:27 PM
Subject: Re: httpclient version upgrade causing SSL exceptions
I unreverted the changes and committed since this was already in the
codebase before.
Let me know if it helps.
On Mon, Nov 7, 2011 at 4:22 PM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> Paul, seems like the right thing to do if we want to use 4.1.2. Do you
> have a link to previous thread on this?
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Paul Lindner <li...@inuus.com>
> To: dev@shindig.apache.org,
> Cc: HttpComponents Project <de...@hc.apache.org>, Ryan J
> Baxter/Westford/IBM@Lotus
> Date: 11/07/2011 04:17 PM
> Subject: Re: httpclient version upgrade causing SSL exceptions
>
>
>
> 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 <ol...@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 <rj...@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 <se...@apache.org>
> > > > To: Ryan J Baxter/Westford/IBM@Lotus,
> > > > Cc: dev@shindig.apache.org, HttpComponents Project
> > > > <de...@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 <rj...@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
>
>
>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: httpclient version upgrade causing SSL exceptions
Posted by Paul Lindner <li...@inuus.com>.
I unreverted the changes and committed since this was already in the
codebase before.
Let me know if it helps.
On Mon, Nov 7, 2011 at 4:22 PM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> Paul, seems like the right thing to do if we want to use 4.1.2. Do you
> have a link to previous thread on this?
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Paul Lindner <li...@inuus.com>
> To: dev@shindig.apache.org,
> Cc: HttpComponents Project <de...@hc.apache.org>, Ryan J
> Baxter/Westford/IBM@Lotus
> Date: 11/07/2011 04:17 PM
> Subject: Re: httpclient version upgrade causing SSL exceptions
>
>
>
> 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 <ol...@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 <rj...@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 <se...@apache.org>
> > > > To: Ryan J Baxter/Westford/IBM@Lotus,
> > > > Cc: dev@shindig.apache.org, HttpComponents Project
> > > > <de...@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 <rj...@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
>
>
>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: httpclient version upgrade causing SSL exceptions
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Paul, seems like the right thing to do if we want to use 4.1.2. Do you
have a link to previous thread on this?
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Paul Lindner <li...@inuus.com>
To: dev@shindig.apache.org,
Cc: HttpComponents Project <de...@hc.apache.org>, Ryan J
Baxter/Westford/IBM@Lotus
Date: 11/07/2011 04:17 PM
Subject: Re: httpclient version upgrade causing SSL exceptions
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 <ol...@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 <rj...@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 <se...@apache.org>
> > > To: Ryan J Baxter/Westford/IBM@Lotus,
> > > Cc: dev@shindig.apache.org, HttpComponents Project
> > > <de...@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 <rj...@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
Re: httpclient version upgrade causing SSL exceptions
Posted by Paul Lindner <li...@inuus.com>.
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 <ol...@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 <rj...@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 <se...@apache.org>
> > > To: Ryan J Baxter/Westford/IBM@Lotus,
> > > Cc: dev@shindig.apache.org, HttpComponents Project
> > > <de...@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 <rj...@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
Re: httpclient version upgrade causing SSL exceptions
Posted by Paul Lindner <li...@inuus.com>.
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 <ol...@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 <rj...@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 <se...@apache.org>
> > > To: Ryan J Baxter/Westford/IBM@Lotus,
> > > Cc: dev@shindig.apache.org, HttpComponents Project
> > > <de...@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 <rj...@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
Re: httpclient version upgrade causing SSL exceptions
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2011-11-07 at 19:33 +0000, sebb AT ASF wrote:
> On 7 November 2011 19:28, Ryan J Baxter <rj...@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 <se...@apache.org>
> > To: Ryan J Baxter/Westford/IBM@Lotus,
> > Cc: dev@shindig.apache.org, HttpComponents Project
> > <de...@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 <rj...@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
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2011-11-07 at 19:33 +0000, sebb AT ASF wrote:
> On 7 November 2011 19:28, Ryan J Baxter <rj...@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 <se...@apache.org>
> > To: Ryan J Baxter/Westford/IBM@Lotus,
> > Cc: dev@shindig.apache.org, HttpComponents Project
> > <de...@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 <rj...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: httpclient version upgrade causing SSL exceptions
Posted by sebb AT ASF <se...@apache.org>.
On 7 November 2011 19:28, Ryan J Baxter <rj...@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
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: sebb AT ASF <se...@apache.org>
> To: Ryan J Baxter/Westford/IBM@Lotus,
> Cc: dev@shindig.apache.org, HttpComponents Project
> <de...@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 <rj...@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
Re: httpclient version upgrade causing SSL exceptions
Posted by sebb AT ASF <se...@apache.org>.
On 7 November 2011 19:28, Ryan J Baxter <rj...@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
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: sebb AT ASF <se...@apache.org>
> To: Ryan J Baxter/Westford/IBM@Lotus,
> Cc: dev@shindig.apache.org, HttpComponents Project
> <de...@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 <rj...@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
>>
>
>
>
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Ryan J Baxter <rj...@us.ibm.com>.
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. Is there anything we as the the Shindig community can do to
help out?
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: sebb AT ASF <se...@apache.org>
To: Ryan J Baxter/Westford/IBM@Lotus,
Cc: dev@shindig.apache.org, HttpComponents Project <de...@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 <rj...@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:405 ms
> 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
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Ryan J Baxter <rj...@us.ibm.com>.
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. Is there anything we as the the Shindig community can do to
help out?
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: sebb AT ASF <se...@apache.org>
To: Ryan J Baxter/Westford/IBM@Lotus,
Cc: dev@shindig.apache.org, HttpComponents Project <de...@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 <rj...@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:405 ms
> 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
>
Re: httpclient version upgrade causing SSL exceptions
Posted by sebb AT ASF <se...@apache.org>.
On 7 November 2011 18:45, Ryan J Baxter <rj...@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:405 ms
> 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
Re: httpclient version upgrade causing SSL exceptions
Posted by sebb AT ASF <se...@apache.org>.
On 7 November 2011 18:45, Ryan J Baxter <rj...@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:405 ms
> 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
>
Re: No snapshot since the new year
Posted by daviesd <da...@oclc.org>.
Thanks Paul!
On 1/10/12 6:50 PM, "Paul Lindner" <li...@inuus.com> wrote:
> JENKINS-12259 caused the build server to do bad things.
> I just updated and kicked off a SNAPSHOT build. Should be available in the
> next hour or so.
>
>
>
> On Tue, Jan 10, 2012 at 3:44 PM, daviesd <da...@oclc.org> wrote:
>
>> I hate to be a pest, but does anyone have an update on this? I¹m still
>> only
>> seeing 12/26 as the latest artifact. This is affecting my daily build.
>>
>> Thanks,
>> doug
>>
>>
>> On 1/9/12 1:28 PM, "daviesd" <da...@oclc.org> wrote:
>>
>>> Any ideas on this? I¹m still showing 12/26 as the last builds at
>>>
>>>
>>
https://repository.apache.org/content/groups/public/org/apache/shindig/shindi>>
g
>>> -common/3.0.0-SNAPSHOT/
>>>
>>> Also, ideas when we might see a beta5?
>>>
>>> doug
>>>
>>>
>>> On 1/6/12 9:58 AM, "daviesd" <da...@oclc.org> wrote:
>>>
>>>> Thanks. Are snapshots happening? I don¹t seem to be picking up anything
>> new
>>>> since 12/26. Could be an issue on my end.
>>>>
>>>> doug
>>>>
>>>>
>>>> On 1/3/12 4:21 PM, "Paul Lindner" <li...@inuus.com> wrote:
>>>>
>>>>> ugh. I reverted the revert. I'll get it back in place.
>>>>>
>>>>>
>>>>> commit f30c4decb5332f18acbacacedd29dee7df54b12e
>>>>> Author: Paul Lindner <li...@apache.org>
>>>>> Date: Mon Dec 26 10:44:42 2011 +0000
>>>>>
>>>>> fix deprecated usage for httpclient
>>>>>
>>>>> git-svn-id:
>>>>>
>> https://svn.apache.org/repos/asf/shindig/trunk@122470813f79535-47bb-0310-995
>>>>> 6-ffa450edef68
>>>>>
>>>>>
>>>>> On Tue, Jan 3, 2012 at 12:46 PM, daviesd <da...@oclc.org> wrote:
>>>>>
>>>>>>> Did this change again recently? The ssl certificate error is back.
>>>>>>>
>>>>>>> doug
>>>>>>>
>>>>>>>
>>>>>>> On 11/7/11 1:45 PM, "Ryan J Baxter" <rj...@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.
>>>>>>>>>
>>>>>>>>> * [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:
>> 405
>> ms
>>>>>>>>> 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 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$HttpFetchCallab>>
>> >>
>> le.
>>>>>>>>> call(
>>>>>>>>> MultipleResourceHttpFetcher.java:105)
>>>>>>>>> at
>>>>>>>>>
>>>>>>>
>>>>>>
>>
>> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallab>>
>> >>
>> le.
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>
>>
Re: No snapshot since the new year
Posted by Paul Lindner <li...@inuus.com>.
JENKINS-12259 caused the build server to do bad things.
I just updated and kicked off a SNAPSHOT build. Should be available in the
next hour or so.
On Tue, Jan 10, 2012 at 3:44 PM, daviesd <da...@oclc.org> wrote:
> I hate to be a pest, but does anyone have an update on this? I¹m still
> only
> seeing 12/26 as the latest artifact. This is affecting my daily build.
>
> Thanks,
> doug
>
>
> On 1/9/12 1:28 PM, "daviesd" <da...@oclc.org> wrote:
>
> > Any ideas on this? I¹m still showing 12/26 as the last builds at
> >
> >
> https://repository.apache.org/content/groups/public/org/apache/shindig/shindig
> > -common/3.0.0-SNAPSHOT/
> >
> > Also, ideas when we might see a beta5?
> >
> > doug
> >
> >
> > On 1/6/12 9:58 AM, "daviesd" <da...@oclc.org> wrote:
> >
> >> Thanks. Are snapshots happening? I don¹t seem to be picking up anything
> new
> >> since 12/26. Could be an issue on my end.
> >>
> >> doug
> >>
> >>
> >> On 1/3/12 4:21 PM, "Paul Lindner" <li...@inuus.com> wrote:
> >>
> >>> ugh. I reverted the revert. I'll get it back in place.
> >>>
> >>>
> >>> commit f30c4decb5332f18acbacacedd29dee7df54b12e
> >>> Author: Paul Lindner <li...@apache.org>
> >>> Date: Mon Dec 26 10:44:42 2011 +0000
> >>>
> >>> fix deprecated usage for httpclient
> >>>
> >>> git-svn-id:
> >>>
> https://svn.apache.org/repos/asf/shindig/trunk@122470813f79535-47bb-0310-995
> >>> 6-ffa450edef68
> >>>
> >>>
> >>> On Tue, Jan 3, 2012 at 12:46 PM, daviesd <da...@oclc.org> wrote:
> >>>
> >>>> > Did this change again recently? The ssl certificate error is back.
> >>>> >
> >>>> > doug
> >>>> >
> >>>> >
> >>>> > On 11/7/11 1:45 PM, "Ryan J Baxter" <rj...@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.
> >>>>> > >
> >>>>> > > * [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:
> 405
> ms
> >>>>> > > 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 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$HttpFetchCallab>>>>
> le.
> >>>>> > > call(
> >>>>> > > MultipleResourceHttpFetcher.java:105)
> >>>>> > > at
> >>>>> > >
> >>>> >
> >>>>
>
> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallab>>>>
> le.
> >>>>> > > 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
> >>>>> > >
> >>>> >
> >>>> >
> >>>> >
> >>>
>
>
No snapshot since the new year
Posted by daviesd <da...@oclc.org>.
I hate to be a pest, but does anyone have an update on this? I¹m still only
seeing 12/26 as the latest artifact. This is affecting my daily build.
Thanks,
doug
On 1/9/12 1:28 PM, "daviesd" <da...@oclc.org> wrote:
> Any ideas on this? I¹m still showing 12/26 as the last builds at
>
> https://repository.apache.org/content/groups/public/org/apache/shindig/shindig
> -common/3.0.0-SNAPSHOT/
>
> Also, ideas when we might see a beta5?
>
> doug
>
>
> On 1/6/12 9:58 AM, "daviesd" <da...@oclc.org> wrote:
>
>> Thanks. Are snapshots happening? I don¹t seem to be picking up anything new
>> since 12/26. Could be an issue on my end.
>>
>> doug
>>
>>
>> On 1/3/12 4:21 PM, "Paul Lindner" <li...@inuus.com> wrote:
>>
>>> ugh. I reverted the revert. I'll get it back in place.
>>>
>>>
>>> commit f30c4decb5332f18acbacacedd29dee7df54b12e
>>> Author: Paul Lindner <li...@apache.org>
>>> Date: Mon Dec 26 10:44:42 2011 +0000
>>>
>>> fix deprecated usage for httpclient
>>>
>>> git-svn-id:
>>> https://svn.apache.org/repos/asf/shindig/trunk@122470813f79535-47bb-0310-995
>>> 6-ffa450edef68
>>>
>>>
>>> On Tue, Jan 3, 2012 at 12:46 PM, daviesd <da...@oclc.org> wrote:
>>>
>>>> > Did this change again recently? The ssl certificate error is back.
>>>> >
>>>> > doug
>>>> >
>>>> >
>>>> > On 11/7/11 1:45 PM, "Ryan J Baxter" <rj...@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.
>>>>> > >
>>>>> > > * [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: 405
ms
>>>>> > > 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 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$HttpFetchCallab>>>>
le.
>>>>> > > call(
>>>>> > > MultipleResourceHttpFetcher.java:105)
>>>>> > > at
>>>>> > >
>>>> >
>>>>
org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallab>>>>
le.
>>>>> > > 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
>>>>> > >
>>>> >
>>>> >
>>>> >
>>>
Re: httpclient version upgrade causing SSL exceptions
Posted by daviesd <da...@oclc.org>.
Any ideas on this? I¹m still showing 12/26 as the last builds at
https://repository.apache.org/content/groups/public/org/apache/shindig/shind
ig-common/3.0.0-SNAPSHOT/
Also, ideas when we might see a beta5?
doug
On 1/6/12 9:58 AM, "daviesd" <da...@oclc.org> wrote:
> Thanks. Are snapshots happening? I don¹t seem to be picking up anything new
> since 12/26. Could be an issue on my end.
>
> doug
>
>
> On 1/3/12 4:21 PM, "Paul Lindner" <li...@inuus.com> wrote:
>
>> ugh. I reverted the revert. I'll get it back in place.
>>
>>
>> commit f30c4decb5332f18acbacacedd29dee7df54b12e
>> Author: Paul Lindner <li...@apache.org>
>> Date: Mon Dec 26 10:44:42 2011 +0000
>>
>> fix deprecated usage for httpclient
>>
>> git-svn-id:
>> https://svn.apache.org/repos/asf/shindig/trunk@122470813f79535-47bb-0310-9956
>> -ffa450edef68
>>
>>
>> On Tue, Jan 3, 2012 at 12:46 PM, daviesd <da...@oclc.org> wrote:
>>
>>> > Did this change again recently? The ssl certificate error is back.
>>> >
>>> > doug
>>> >
>>> >
>>> > On 11/7/11 1:45 PM, "Ryan J Baxter" <rj...@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.
>>>> > >
>>>> > > * [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: 405
ms
>>>> > > 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 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$HttpFetchCallabl>>>
e.
>>>> > > call(
>>>> > > MultipleResourceHttpFetcher.java:105)
>>>> > > at
>>>> > >
>>> >
>>>
org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallabl>>>
e.
>>>> > > 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
>>>> > >
>>> >
>>> >
>>> >
>>
Re: httpclient version upgrade causing SSL exceptions
Posted by daviesd <da...@oclc.org>.
Thanks. Are snapshots happening? I don¹t seem to be picking up anything new
since 12/26. Could be an issue on my end.
doug
On 1/3/12 4:21 PM, "Paul Lindner" <li...@inuus.com> wrote:
> ugh. I reverted the revert. I'll get it back in place.
>
>
> commit f30c4decb5332f18acbacacedd29dee7df54b12e
> Author: Paul Lindner <li...@apache.org>
> Date: Mon Dec 26 10:44:42 2011 +0000
>
> fix deprecated usage for httpclient
>
> git-svn-id:
> https://svn.apache.org/repos/asf/shindig/trunk@122470813f79535-47bb-0310-9956-
> ffa450edef68
>
>
> On Tue, Jan 3, 2012 at 12:46 PM, daviesd <da...@oclc.org> wrote:
>
>> > Did this change again recently? The ssl certificate error is back.
>> >
>> > doug
>> >
>> >
>> > On 11/7/11 1:45 PM, "Ryan J Baxter" <rj...@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.
>>> > >
>>> > > * [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: 405 ms
>>> > > 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 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
>>> > >
>> >
>> >
>> >
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Paul Lindner <li...@inuus.com>.
ugh. I reverted the revert. I'll get it back in place.
commit f30c4decb5332f18acbacacedd29dee7df54b12e
Author: Paul Lindner <li...@apache.org>
Date: Mon Dec 26 10:44:42 2011 +0000
fix deprecated usage for httpclient
git-svn-id:
https://svn.apache.org/repos/asf/shindig/trunk@122470813f79535-47bb-0310-9956-ffa450edef68
On Tue, Jan 3, 2012 at 12:46 PM, daviesd <da...@oclc.org> wrote:
> Did this change again recently? The ssl certificate error is back.
>
> doug
>
>
> On 11/7/11 1:45 PM, "Ryan J Baxter" <rj...@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.
> >
> > * [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: 405 ms
> > 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 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
> >
>
>
>
Re: httpclient version upgrade causing SSL exceptions
Posted by daviesd <da...@oclc.org>.
Did this change again recently? The ssl certificate error is back.
doug
On 11/7/11 1:45 PM, "Ryan J Baxter" <rj...@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.
>
> * [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: 405 ms
> 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 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
>