Page 2 of 19
Posted: Thu Jan 13, 2011 9:05 am
Just tried it with my wife's gmail account. She did not have a calendar, so initialized it with Google. Then used my sync link substituting https for http. Same result. Google reformatted the https to http. No synchronization.
Posted: Thu Jan 13, 2011 9:25 am
Thanks for that. That may be enough clue to solve it.
I note looking at my google calendar that my mail.liddicott.com https URL has become an http url too.
I wonder if I add an http->https redirector to my script, like church does, if it will stop working with google. I'll try later on (on a different liddicott.com url so I don't break this work-around)
I'm guessing that the bug is with google, that they are just very eager to convert https to http - probably it is cheaper on CPU power and network traffic that way (multipled by their number of customers could be a lot!).
I'm going to guess that if the http request gave a 4xx or 5xx status response code that google would have stayed with the entered https url instead of falling bacl to http.
I guess that a 2xx or 3xx status response code makes it think that http request was valid and that therefore http can be used instead.
Then, the 302 redirected URL is processed and all those steps repeated with the new URL - first falling back to http, and so on, till it gets fed up of too many re-directs.
If I am right, google should treat a 3xx status code as a reason to not use http instead of https. They could also use a "don't fall-back if it gives us a URL we already tried".
Church devs can check this by looking for multiple repeated requests from google for the same URL.
They may be able to work around by issuing a different response code for the redirect, but I don't see any ideal codes.
I think the real work around would be for church to recommend https not http for calendar sync, and make sure that http links return 404
Posted: Thu Jan 13, 2011 9:50 am
My link to your redirect is still set as https by Google. Google did NOT convert it to http.
Posted: Thu Jan 13, 2011 10:09 am
Hmmm... and my lds link has stopped working in google calendar... so I've got no ideas left apart from replicate some of the redirection the church service does and see what problems arise.
For now I'll just use my work-around.
Thanks for the tests, tortdog
Posted: Thu Jan 13, 2011 10:39 am
Based on the difference between the official lds.org link and samliddicott's link, it appears that the fact that the lds.org https certificate has a mismatched domain name (*.lds.org vs. lds.org) may be causing google problems.
I was playing around with the various URLs using a command line "wget" and found that the http: URL's get 302 redirected to https: always, and I have to tell wget to ignore the problem with the domain name mismatch in order to receive any data.
Just my $0.02,
Posted: Thu Jan 13, 2011 10:50 am
Sam, thanks for this! That fixed it for me! It will tide me over until the Church fixes their certificate.
Posted: Thu Jan 13, 2011 1:37 pm
Sam's proxy worked for me too. Google integration has been broken for me since the move from new.lds.org, though I have been able to bring the calendar down to my iPod directly w/o going to Google first.
Posted: Thu Jan 13, 2011 7:42 pm
chrissv wrote:Based on the difference between the official lds.org link and samliddicott's link, it appears that the fact that the lds.org https certificate has a mismatched domain name (*.lds.org vs. lds.org) may be causing google problems.
Inspired by the checking going on here, I tried a bit of my own. I installed WGET and played with it. I hoped that by changing the URL a bit I could make it work. No joy.
If I use "https://lds.org/church-calendar
", I get the message: "ERROR: certificate common name `*.lds.org' doesn't match requested host name `lds.org'."
Ok, that might be easy to fix. So I tried "https://www.lds.org/church-calendar
". I got the message:
ERROR: cannot verify [url]http://www.lds.org's[/url] certificate, issued by `/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/CN=USERTrust Legacy Secure Server CA': Unable to locally verify the issuer's authority.
If I understand this correctly, it's not trusting the issuer. Not much I can do about it there.
What I'd like to see is someone for who the Google sync DOES work try WGET and see what happens. I'm wondering if it's going to a different church server that is properly certificated, or if Google is playing by different rules depending on the server your account it on.
Posted: Fri Jan 14, 2011 5:48 am
Trying to use the work around and got this error from Google: 'Could not fetch the URL because robots.txt prevents us from crawling the URL'.
Posted: Fri Jan 14, 2011 7:08 am
EmrolGould wrote:Trying to use the work around and got this error from Google: 'Could not fetch the URL because robots.txt prevents us from crawling the URL'.
Fair enough. I've deleted the robots.txt - was trying to stop google indexing what should be a private URL in their search engine, but maybe the http response headers will be enough.
Please try again