My question is almost identical to the one found here: Facebook canvas application never loads <body> contents?
However I'm running flask through Heroku's cedar stack. My url has always been the heroku subdomain so the solution above does not apply. Most of the time the application never loads past the head tags. Has anyone made any progress on this problem?
What I've found is that the post to Heroku is not asking for all the required bytes. Here is what my POST looks like from Heroku logs:
2012-07-06T02:33:33+00:00 app[web.1]: 10.191.221.194 - - [06/Jul/2012 02:33:33] "POST /?fb_source=search&ref=ts HTTP/1.1" 200 -
2012-07-06T02:33:33+00:00 heroku[router]: POST simple-frost-5348.herokuapp.com/?fb_source=search&ref=ts dyno=web.1 queue=0 wait=0ms service=3040ms status=200 bytes=2757
You'll see it is asking for 2757 bytes, which is exactly where the truncation occurs in my app.
It happens only after you log in and connect with the FB app. Hope this helps.
Related
I'm able to signup as a user and login as a user successfully on my local host, but on Heroku I receive an application error. It looks like the request is a timeout issue (H12 / 503 error). I'm confused because the login and signup was working fine about a month ago. I took a break from the project and at the time Heroku was deployed successfully and was working. Now I'm having problems on Heroku and don't know how I can fix the issue or what caused it in the first place.
This is my heroku log -
2021-04-13T03:30:27.742004+00:00 heroku[router]: at=error code=H12 desc="Request timeout" method=POST path="/auth/signup" host=reciperec-cristina.herokuapp.com request_id=e0e634e0-fd8e-4517-b428-f319e6beaddb fwd="73.202.97.117" dyno=web.1 connect=1ms service=30000ms status=503 bytes=0 protocol=https
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.
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'd like to be able to have two sets of slides, produced from two different notebooks, open at once in my browser. This use case is not supported, as far as I can tell, by the option --post serve of ipython nbconvert --to slides (of course, I'd be happy to be disproved).
My tactic has been to start a local server, as in
python -m SimpleHTTPServer 8001
and open the slide shows like this
google-chrome http://127.0.0.1:8001/my.slides.html
but now I get a bunch of messages alike
127.0.0.1 - - [31/Mar/2015 12:03:49] code 404, message File not found
127.0.0.1 - - [31/Mar/2015 12:03:49] "GET /reveal.js/css/reveal.css HTTP/1.1" 404 -
whose meaning is quite clear to me... so I did
ln -s /path/to/local/copy/of/reveal.js/ .
google-chrome http://127.0.0.1:8001/`
but now I have
127.0.0.1 - - [31/Mar/2015 12:07:29] code 404, message File not found
127.0.0.1 - - [31/Mar/2015 12:07:29] "GET /custom.css HTTP/1.1" 404 -
examining the source of my.slides.html I see the lines
<!-- Custom stylesheet, it must be in the same directory as the html file -->
<link rel="stylesheet" href="custom.css">
so I'm bound to the conclusion that --post serve does an awful lot of things at my back and that I'm out of luck in my attempt to save a standalone slide-show and have it served by a local HTTP server.
How can I have a properly served slide show without resorting to --post serve?
We have a Facebook application implemented as tabs in a page. However, for certain users, it does weird redirects. This doesn't happen for everyone though, which is why I can't wrap my head around it.
When I go in Chrome incognito mode to our page without being logged in, it seems to happen to me too. What happens exactly?
The multiple tabs on the left of the page are our application tabs. However, something seems to go wrong when clicking on them. I always get the same frontpage, which is the 'Socialabs' page. My heroku logs indicate this:
2012-02-17T14:29:09+00:00 app[web.1]: 193.191.150.2 - - [17/Feb/2012 14:29:09] "POST /small HTTP/1.1" 302 - 0.0025
2012-02-17T14:29:09+00:00 heroku[router]: POST socialapp.herokuapp.com/small dyno=web.1 queue=0 wait=0ms service=28ms status=302 bytes=0
2012-02-17T14:29:09+00:00 app[web.1]: 193.191.150.2 - - [17/Feb/2012 14:29:09] "GET / HTTP/1.1" 302 - 0.0009
2012-02-17T14:29:09+00:00 heroku[router]: GET socialapp.herokuapp.com/ dyno=web.1 queue=0 wait=0ms service=10ms status=302 bytes=0
2012-02-17T14:29:09+00:00 app[web.1]: 193.191.150.2 - - [17/Feb/2012 14:29:09] "GET /tab HTTP/1.1" 200 2173 0.0112
2012-02-17T14:29:09+00:00 heroku[router]: GET socialapp.herokuapp.com/tab dyno=web.1 queue=0 wait=0ms service=14ms status=200 bytes=2173
What seems to happen when a user visits, in this case, the 'Small' tab is as follows:
a POST happens to the /small route of our application. This is to be expected. However, instead of rendering our erb template for that route, we get another redirect: /. This route redirects to /tab, as specified in our routes.
I can't figure out why /small redirects to /. The route looks like this in our sinatra application:
get "/contact" do
erb :contact
end
post "/contact" do
#on fb post we redirect to get route and display view
redirect '/contact'
end
I really can't figure this out. The complete contents of my app.rb file can be found in this gist: https://gist.github.com/1864561
Thanks in advance
From your app.rb you have:
before do
# HTTPS redirect
if settings.environment == :production && request.scheme != 'https'
redirect "https://#{request.env['HTTP_HOST']}"
end
end
I don't know the Facebook api or how their apps work, but it looks like it could be this filter that's redirecting any none https request to /.