I have recently renewed my website, but for some reason the Facebook Open Graph Debugger is not able to re-scrape my new og tags.
When I enter the website, I receive a couple of error messages which makes no sense.
For example:
1.Circular redirect path detected (see 'Redirect Path' section for details).
2. URL requested a HTTP redirect, but it could not be followed.
When I debug my website, and see which HTML status code is given, it is 200 OK. So where does the 301 come from which the Facebook Debugger detects?
What am I missing in my set up?
Thanks in advance.
Redirecting error have happened to me on websites that redirect http to https.
The errors output explains explicitly what is the path the debugger needed to pass. In my case it showed me that it had to pass the following path: https >> http >> https.
This have occurred since the page url i tried to share used https, but in the op meta definition, I have defined it as http. Fixing that resolved all.
Related
I run a website which seems to have a problem with 303 Redirects.
The CMS is TYPO3 9.5.24.
I don't know where the redirects are coming from. Unfortunately the 303 redirects are not listed in the network tab of the console (testet Chrome, FF). Why not?
The Problem is Facebook is not able to scrape the pages. Their Sharing debugger (https://developers.facebook.com/tools/debug/) tells me "URL requested a HTTP redirect, but it could not be followed."
I checked with https://www.redirect-checker.org/index.php, there I get a loop of 303 redirects.
I can view the website in any browser just fine, no problems there.
I checked .htaccess and the TYPO3 Backend for 303 redirects, but found nothing.
I suspected a server (nginx) misconfiguration but can't figure it out. Other websites on the same server do not have that problem.
Has anyone experienced similar problems?
Found the redirection in our custom code. Had nothing to do with Typo3.
Sorry for the confusion.
Thanks Peter Kraume, the curl check helped me to find the problem.
Appearently modern browsers ignore a 303 redirect loop, so i was not able to see anything in browser console.
Can be closed.
I found that anybody show their page to user, then 302 redirect to my site,
I want stop it.
I thought there would be referer in request header, but didn't!
I tested this in chrome72.0.3626.121 and ie11, and use fiddler to catch Request,
there have no referer header in all request.
And my server side code can't see referer too.
How can I stop 302 redirect to my site??
It's possible these days for sites to disable adding a referrer when a user follows a link. This is a privacy feature.
The result of sites using this feature is that you can't tell if:
A) A user opened your site directly from the addressbar
B) A user came to your site from somewhere else.
If you could tell the difference, it means the privacy feature is not working. Your only option is to block anyone with no referrer header, but then you might block a lot of other users as well.
There is one other common reason for this though, if you are running an insecure (http) site and you are being linked from secure (https://) site. It might be possible to get the referrer back in this case by upgrading your site to https.
I just moved my blog to https and, of course, all the facebook shares counters are now reset to 0.
I've spent several hours reading stuff online and I got the solution to point the og:url tag to the old urls (with http instead of https).
It worked for a day but now all the counters are back to 0.
The strange thing is that if I check the urls (both with https and http) with the open graph debugger it returns me 0 shares for both the urls!
I really don't know what to do! Is there a way to have back the counters of the http-version of the urls? Or, as an alternative, is there a way to sum the two counters?
p.s. I already activated the 301 redirect for the whole blog in my .htaccess file.
Facebook treats HTTP and HTTPS as two different URLs and therefor two different Open Graph objects, even if the rest of it is the same.
p.s. I already activated the 301 redirect for the whole blog in my .htaccess file.
And that's your mistake ... You need to keep the old HTTP URLs available for the FB scraper to read the OG meta data from; if you redirect the scraper to the HTTPS version as well, then it concludes that the HTTPS versions was the actual correct URL for this piece of content - and therefor you have just undone what you tried to do by having og:url point to the old HTTP address.
See https://developers.facebook.com/docs/plugins/faqs#faq_1149655968420144 for more details.
The scraper can be recognized by the User-Agent request header it sends - see https://developers.facebook.com/docs/sharing/webmasters/crawler
(How to exclude clients that send a certain user agent from redirection via .htaccess is something that should be easy enough to research.)
One of my pages in my domain is set up as a redirect from aweber, so when I confirm on the link on an email optin from aweber it redirects to this page MyPage.html and includes a welcome message with the name I signed up with.
Now granted I am not sure if this is something to do with aweber set up for redirect although it's very easy to do (basically paste the URL in settings you want to redirect to) and I have double/triple checked it. I also contacted aweber support who said it can be the javascript for personalisation embedded in the Head section of the redirect page that can cause this error. I have removed this code and can confirm it is not the javascript or redirect causing it hence my appearance here.
I also have another portion of the site using this redirect and personalisation and it works fine.
Now when I click on the link in my email from aweber it gives me this error:
Forbidden
You don't have permission to access /mypage.html on this server.
Additionally, a 500 Internal Server Error error was encountered while trying to use an >ErrorDocument to handle the request.
And the redirect URL is below so I can see it is redirecting with my details ok but failing to give me access to the page.
mysite.com/mypage.html?email=myemail%40yahoo.co.uk&from=myemail%40yahoo.co.uk&meta_adtracking=my_web_site&meta_message=1001&name=MyName&unit=MyAweberListName&add_url=http%3A%2F%2Fwww.MySite.com%2FthankyouPage.html&add_notes=xx.xx.xx.xxx
All my pages have access permission 644 and the page is a copy of one of my other pages, which works fine, I've not added anything, changed anything, only removed text lines and graphics.
I just also tried remaking the landing page and it failed once more. Funnily enough though when I manually type the page into the URL bar up it comes; this worked before with the original page as well!
This works:
mysite.com/mypage.html
This [redirect] doesn't and gives the error described above
mysite.com/mypage.html?email=myemail%40yahoo.co.uk&from=myemail%40yahoo.co.uk&meta_adtracking=my_web_site&meta_message=1001&name=MyName&unit=MyAweberListName&add_url=http%3A%2F%2Fwww.MySite.com%2FthankyouPage.html&add_notes=xx.xx.xx.xxx
Any ideas on getting to the bottom of this would be greatly appreciated.
Host is hostgator
Problem
I have an application driving a tab on a client's page. The application works correctly if the user has not enabled FB's "secure browsing" feature. If attempting to view over HTTPS, the iframe doesn't even appear (no errors, no mixed-content warnings). When correctly loading over HTTP, the div with the id "pagelet_app_runner" has an iframe inserted into it and the application content is loaded inside there. Over HTTPS, this div remains empty and the iframe is not inserted into the page. There are no Javascript errors appearing in Firebug or Chrome's equivalent console.
Why I'm Asking Here
The host has a valid SSL certificate and there is no 'mixed content' at the URL in question. I can successfully view the content over HTTP or HTTPS by visiting the URL directly, and I can do the same by visiting apps.facebook.com/canvasURL/tabURL. It is only when attempting to view within a Page Tab that the HTTPS load fails as described above. My application is configured with both regular and secure canvas and tab URLs.
Attempted Debugging
I've recorded some sessions with Charles but since the iframe isn't being inserted into the page, I think I'm coming at the problem after it's already occured. I'm no Charles expert so happy to be corrected here.
Apache isn't seeing any request (in either regular or ssl logs) for the affected loads. non-SSL loads come through as expected in access_log.
Plea for Help
I'm out of ideas for debugging this. Does anybody have any suggestions? What really obvious and stupid mistake might I have made? :)
edit: nicer formatting
Your app canvas URL is https://skinnycomp.nextstudio.com.au/skinnycowcomps/ , which send 404 error to Facebook proxy (request is going through proxy when viewing app via tab), also when viewing your app via apps (https://apps.facebook.com/122381834451561/), again 404... maybe Facebook proxy is ignoring 404 and posting blank...
Try changing canvas URL to https://skinnycomp.nextstudio.com.au/skinnycowcomps/tab, also you can check if your app is accessed via page tab, in signed_request there should be page_id...
23:51:15.379[549ms][total 1667ms] Status: 404[Not Found]
GET https://skinnycomp.nextstudio.com.au/skinnycowcomps/
This is a real longshot since I'm sure you've triple checked all the settings, but the blank page can happen if an invalid url is specified in the Page Tab URL field in the app settings. Since it only happens on https, it would imply something specifically with the Secure Page Tab URL entry. It might be worth checking that again, and maybe even re-saving it or changing it to something else to see if it helps.
I was using relative URLs for the regular and secure tab URL fields. From memory relative URLs here were mandatory at some point in the past. It appears now that a relative URL will still work for HTTP but not for HTTPs. Fix: absolute URLs. Hopefully FB update their field validation to match what's required too.