Workaround to fix calendar sync problems
-
- Member
- Posts: 165
- Joined: Mon Jul 28, 2008 8:00 am
- Location: Austin, Texas
- samliddicott
- Member
- Posts: 77
- Joined: Wed May 20, 2009 9:48 am
- Location: England
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
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
- samliddicott
- Member
- Posts: 77
- Joined: Wed May 20, 2009 9:48 am
- Location: England
- chrissv
- New Member
- Posts: 35
- Joined: Fri Mar 02, 2007 9:17 am
- Location: Dudley, MA
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,
Steven
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,
Steven
- BellMR
- New Member
- Posts: 25
- Joined: Wed Apr 04, 2007 11:03 am
- Location: Spring, TX - USA
-
- Community Administrator
- Posts: 34421
- Joined: Sat Jan 20, 2007 2:53 pm
- Location: U.S.
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.
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.
So we can better help you, please edit your Profile to include your general location.
So we can better help you, please edit your Profile to include your general location.
- emrolgould
- New Member
- Posts: 21
- Joined: Fri Dec 07, 2007 8:32 pm
- Location: Chaguanas, Trinidad & Tobago
- samliddicott
- Member
- Posts: 77
- Joined: Wed May 20, 2009 9:48 am
- Location: England
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