I have done extensive searches on the Internet for a solution to this issue, but all that I can find is always related to making timeout adjustments on a Linux machine running Apache. I am running IIS version 10 on Windows 2019 Server. When Facebook changed it's website approximately 30-days ago, the Open Graph image sharing protocol stopped working properly. An attempt to use the Facebook Developer scraper, I get the following timeout error.
Curl Timeout
The request to scrape the URL timed out.
Curl Error
Curl error: 28 (OPERATION_TIMEOUTED)
I also filed a bug report with Facebook, but they simply closed the report, stating that the problem is with my server or network connection. I opened and inspected the server's error logs, and found no issues. I then setup and inspected the IIS logs, and found that Facebook indeed hit the server properly and fetched an image and reported it back. But the timeout error still occurs and the image is not shared upon an attempt to share it. Here are the records from the IIS logs that seem to indicate that Facebook is indeed contacting my server correctly, except for the fact that they are using "http" rather than "https." This has been reported to Facebook.
2020-12-24 18:31:51 W3SVC3 EDENUSA-FS11 10.1.252.250 GET /images/qr_code/edenusa_qr_code.png - 443 - 69.171.249.113 facebookexternalhit/1.1+(+http://www.facebook.com/externalhit_uatext.php) - www.edenusa.com 200 0 0 70
2020-12-24 18:32:02 W3SVC3 EDENUSA-FS11 10.1.252.250 GET /rent-lighting/lighting/rent_lighting.asp - 443 - 69.171.249.111 facebookexternalhit/1.1+(+http://www.facebook.com/externalhit_uatext.php) - www.edenusa.com 200 0 0 21410
And following is a snippet of the required meta code in our header area, from the home page:
<!DOCTYPE html>
<head>
<title>Rent a Stage | Rent a Sound System | Rent Lighting System | Rent Up Lighting</title>
<meta prefix="fb: https://ogp.me/ns/fb#" property="fb:app_id" content="1376081292633720">
<meta property="og:url" content="https://www.edenusa.com/index.asp" />
<meta property="og:image:type" content="image/jpeg" />
<meta property="og:title" content="Rent a Stage | Rent a Sound System | Rent Lighting System | Rent Up Lighting" />
<meta property="og:image" content="https://www.edenusa.com/images/homepage/compressed/indian_temple_in_chino_hills.jpg" />
<meta property="fb:app_id" content="1376081292633720" />
I've worked on this for over a week now, without resolution. Anybody else having this issue, or know of a way to resolve the timeout issue?
This issue was resolved as follows:
We had to remove REST code in the GLOBAL.ASA that goes out and fetches geographic info (City and State only) based upon the client's IP address. The service endpoint is a bit slow, and required that a longer timeout than might be considered "normal" to be used. So when this code branch was commented out, the Facebook CURL timeout error no longer occurred. We are looking at another IP geographic info service that is faster.
After completing step 1, we found that on the home page ONLY, we had to leave the INDEX.ASP portion of the URL in place. We had code the stripped the "index.asp" off the canonical URL. For unknown reason, Facebook looks at the HTTP header, sees that the original URL has the "index.asp" included, and then compares that to the URL specified in the "og:url" meta tag.
In conclusion, the most recent rollout of Facebook includes new code that configured a shorter timeout value for CURL. This caused websites out on the web with a somewhat shorter startup time, to experience this issue. So for now, the only fix is to monitor a site's startup time, and shorten it down enough for the Facebook debugger/scraper to function as it did before the most recent changes.
Related
I'm trying to get a basic PayPal button on my web page, but I can't even load the API without getting errors. I've asked for help on PayPal's own forum, but no one replies.
Here is my page. I'm running in sandbox mode. I've replaced the actual client ID below with [CLIENTID].
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>PayPal test</title>
</head>
<body>
<script src="https://www.paypal.com/sdk/js?debug=true&client-id=[CLIENTID]"></script>
</body>
</html>
I can add a button to the page, and make a purchase, so the buying process works. But it always throws this error at page load. I'm on Win10, Brave Browser (based on Chromium).
js?debug=true&client…ruzpDLhao-FzS6:2659 unhandled_error
{err: "Error: Invalid json: .↵ at XMLHttpRequest.<anon…[CLIENTID]:2597:55)", timestamp: "1601234382102", referer: "localhost", uid: "9b7c68f416_mtk6mtc6ntq", env: "sandbox"}
env: "sandbox"
err: "Error: Invalid json: .↵ at XMLHttpRequest.<anonymous> (https://www.paypal.com/sdk/js?debug=true&client-id=[CLIENTID]:2597:55)"
referer: "localhost"
timestamp: "1601234382102"
uid: "9b7c68f416_mtk6mtc6ntq"
__proto__: Object
===============================================================
UPDATE
Sorry, I incorrectly wrote I am on Google Chrome. I'm on Brave Browser (based on Chromium). I've tested on Google Chrome and MS Edge, and it works there. Brave is where the errors happen. I've tried to add a new sandbox app, but get the same error. I've used the Brave browser settings to allow my site all privileges, but still the same error.
Live test:
Just loading API: https://www.trainerslab.app/PayPalTest.html
Example from PayPal dev site: https://www.trainerslab.app/PayPalTest2.html
Screenshot:
After using the Python http.server module I'm now trying to convert everything to Bottle and can't even get started. My problem is locating static files - everything I've tried results in a "404" error. So I've tried to reduce everything to the simplest possible example. My top level directory is in "/home/dave/test" and under that is a single file (test.py), and a subdirectory ("/home/dave/test/static") containing the single file "index.html". The html file is pretty basic:
<!DOCTYPE html>
<html lang="en">
<head>
<title>Bottle Test</title>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<h1>Hello, World</h1>
</body>
</html>
If I double click on the file itself, it opens a new browser page and displays the "Hello, World" message. The test.py file is:
#!/usr/bin/env python3
from bottle import route, run, static_file
#route('/static/<filename>')
def server_static(filename):
return static_file(filename, root='/home/dave/test/static')
run(host='localhost', port=8080, debug=True)
If I open a browser window and enter "localhost:8080/index.html" I get back the "Error: 404 Not Found" message and the terminal window where I'm running the script looks like:
$ ./test.py
Bottle v0.12.16 server starting up (using WSGIRefServer())...
Listening on http://localhost:8080/
Hit Ctrl-C to quit.
127.0.0.1 - - [06/Apr/2019 15:31:25] "GET /index.html HTTP/1.1" 404 740
I've tried various permutations of the URL and root parameter but nothing I've tried works. Clearly I'm missing something very basic here. Can somebody tell me what is wrong in in the above files (or URL)?
Thanks,
Dave
I was able to contact the author of Bottle and he responded:
a route matches against the path-part of an HTTP request URL. In your
example, '/static/' would match requests to
http://localhost:8080/static/index.html and serve 'index.html' file
from the '/home/dave/test/static' directory.
"http://localhost:8080/index.html" does not match the route you
specified, thus the 404 error.
I tried this and it did indeed fix the problem.
wget hangs there while it accesses the following website. But when I use a browser to access it, it will be redirected to https://nyulangone.org. Does anybody know why wget can not get redirected in this case? Thanks.
$ wget http://nyumc.org
--2018-02-20 20:27:05-- http://nyumc.org/
Resolving nyumc.org (nyumc.org)... 216.165.125.106
Connecting to nyumc.org (nyumc.org)|216.165.125.106|:80...
When I used wget on the site you mentioned, this is what I get:
--2018-02-21 21:16:38-- http://www.nyumc.org/
Resolving www.nyumc.org (www.nyumc.org)... 216.165.125.112
Connecting to www.nyumc.org (www.nyumc.org)|216.165.125.112|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 179 [text/html]
Saving to: ‘index.html’
index.html 100%[==================================>] 179 --.-KB/s in 0s
2018-02-21 21:16:38 (8.16 MB/s) - ‘index.html’ saved [179/179]
In the index.html file, which bears the logo of NYU Langone Medical Center, it says: "The following URL has been rejected for security concerns. If you believe you have received this message in error, please summit an incident with our helpdesk at 212-263-6868..." So, it may not redirect because the website can detect that you are a bot and not a browser. You could attempt to change the user agent string and other HTTP headers to avoid detection, but I'm not sure why you wouldn't just turn wget on https://nyulangone.org. Judging from information on archive.org, nyumc.org has been redirecting to other sites for at least the last 5 years. It was redirecting to http://www.med.nyu.edu until 2016, at which point it started redirecting to https://www.nyulangone.org.
I hope that helps.
I made a site: http://pravo-trans.eu/
There is all needed og meta tags. But when I want to share link on any social networks nothings happens. I thought it might be cach. But when I used facebook debugger, it said:
The 'og:type' property is required, but not present.
And it's not true because I wrote in <head> this:
<meta property="og:title" content="Проект правовой помощи людям" />
<meta property="og:type" content="website" />
<meta property="og:image" content="/transgender-project.jpg" />
<meta property="og:description" content="Бесплатные юридические консультации и представительство по делам о смене документов (внесение изменений в записи о рождении, паспорта, трудовые книжки, документы об образовании и другие документы)" />
<meta property="og:url" content="http://pravo-trans.eu/" />
<meta property="og:locale" content="ru_RU" />
<link rel="canonical" href="http://pravo-trans.eu/" />
And most strange thing for me happen when I click on "See exactly what our scraper sees for your URL". There I saw that debugger parsed Apache default page instead mine! https://developers.facebook.com/tools/debug/og/echo?q=http%3A%2F%2Fpravo-trans.eu%2F
How it can be and how I can fix it?
After several hours of trying to debug this issue and playing with DNS settings/servers, I have a solution that works for me.
I noticed that requests from Facebook were coming from an IPv6 server, but my Apache VirtualHost declarations did not include the IPv6 address. To debug, I changed the following line in my Apache .conf file:
<VirtualHost IPv4:80>
to:
<VirtualHost IPv4:80 [IPv6]:80>
...and immediately upon restarting Apache, Facebook was able to successfully scrape my site. (Replace IPv4/IPv6 above with your actual addresses of course.)
If by chance you are using Parallels Plesk, as am I, then this is not a permanent solution because Plesk will rewrite the configuration files, so you have to go into the Plesk panel and make sure that your server's IPv6 address is assigned to the Subscription that owns the domain in question. In my case, only the IPv4 was assigned to the subscription.
The setting can be found under "Change Hosting Settings" for each particular Subscription.
We'd like to have the following configuration :
one server is replying to GWT RPC : x.com (the one running Java)
another server is serving js / css / images : y.com (for bandwith optimization)
So the main page is : http://x.com/index.html
and contains this line: <script type="text/javascript" language="javascript" src="http://**x.com**/my-app.nocache.js"></script>
We're getting a SOP error: Unsafe JavaScript attempt to access frame with URL ...
Any suggestion, help about that ?
Add the following to your gwt.xml:
<add-linker name="xsiframe" />
This will generate slightly different code, that can be loaded cross-origin. Your "host page" will still have to be loaded from the same server you run your GWT-RPC servlets on, to not hit the SOP.
See this FAQ entry (the "xs" linker predates the "xsiframe" one, that latter is now preferred, and could eventually even replace the "std", default linker)
You have hit Same Origin Policy which prevents making XMLHTTPRequest to servers other than origin server. This effectively prevents cross-domain GWT-RPC.
The possible workarounds are described in Making cross-site requests:
Run a proxy on your server
Load the JSON response into a <script> tag