Facebook 画布应用程序永远不会加载内容?

发布于 2025-01-06 19:49:30 字数 1448 浏览 1 评论 0原文

我已经构建了一个 Facebook 应用程序,该应用程序应该可以在网络上使用或作为 Facebook 内的画布应用程序使用。我的设置如下:

SERVER             |     FACEBOOK APP     |    CURRENTLY WORKS
-----------------------------------------------------------------------------
localhost          |     quotewarsdev     |   both in app and directly
-----------------------------------------------------------------------------
quotewars2012.com  |     quote_wars       |   only by accessing directly

我使用相同的设置开发和部署了其他 Facebook 应用程序,没有出现任何问题。奇怪的是,Facebook 中 90% 的生产应用程序请求都失败了——应用程序加载了 的大部分内容,然后就崩溃了。有时会加载整个页面。

一个在 Heroku 上的 cedar 堆栈上运行的 Django 应用程序 - 我知道,还没有真正准备好生产 - 但我不认为这是罪魁祸首是该应用程序在 Facebook 之外加载良好。

如果我跟踪服务器日志,我可以看到服务器通过 Facebook 已加载的 部分向上发送 CSS/JS 资源。

  1. 也许 Facebook 正在尝试预先解析该请求,然后按照此处描述的方式提供该请求
  2. 也许 Facebook 对来自 的请求有未记录的加载时间限制?
  3. 也许 Facebook 对 中的请求数量有未记录的限制?

鉴于本地负载没有问题,这些理论都没有意义。

任何人都可以确认上述任何内容或提供任何其他想法吗?

同时,服务器日志中没有任何错误指示,Facebook 应用程序界面中也没有错误报告,并且浏览器中没有任何问题的迹象,我只能随机删除、重新排序并使用 标签进行调试。

I've built a Facebook application which should be available on the web or as a canvas application within Facebook. My setup is like so:

SERVER             |     FACEBOOK APP     |    CURRENTLY WORKS
-----------------------------------------------------------------------------
localhost          |     quotewarsdev     |   both in app and directly
-----------------------------------------------------------------------------
quotewars2012.com  |     quote_wars       |   only by accessing directly

I've developed and deployed other Facebook apps using the same set up with no problems. Bizarrely, 90% of the requests for the production app in Facebook fail- the app loads most of the contents of <head> and then craps out. Occasionally the full page will load.

A Django app running on the cedar stack on Heroku- I know, not really production ready - but I don't think this is the culprit as the app loads fine outside of Facebook.

If I tail the server logs I can see the server sending CSS/JS assets up through the parts of the <head> that Facebook has loaded.

  1. Maybe Facebook is trying to pre-parse the request and then serve it as described here?
  2. Maybe Facebook has an undocumented load time limit on requests from the <head>?
  3. Maybe Facebook has an undocumented limit on number of request in the <head>?

None of these theories make sense given the a problem-free load from local.

Can anyone confirm any of the above or offer any other ideas?

Meanwhile, with no indication of an error in the server logs, no error reports in the Facebook app interface, and no hint of any problems in the browser, I'm left randomly removing, reordering, and futzing with <head> tag to debug this.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

芸娘子的小脾气 2025-01-13 19:49:30

如果这些疯狂的作品能够进入哪怕是一个陷入了最前沿的 Heroku 开发和冷漠的 Facebook 支持之间的绝望泥潭的可怜灵魂的眼睛,那么我在这个地球上的时间就已经度过了。我不会提供任何关于为什么这可以解决问题的理论,但这是我现在所知道的。

在此请求路径中的某个位置,响应被字节或字符任意截断。

Facebook canvas app >> Zerigo DNS add-on >> Cedar Stack / Gunicorn >> Django

我通过用古腾堡项目中的文本替换我的应用程序的全部内容来确认这一点,果然,每次响应都会偶尔被截断相同的字符

删除Zerigo并将Facebook画布应用程序直接指向heroku上的应用程序地址(例如http://quotewars.herokuapp.com/)似乎已经解决了这个问题。

If these mad writings find their way to the eyes of even one poor soul caught in the hopeless mire between bleeding edge heroku development and apathetic facebook support then my time on this earth will have been well spent. I'm not going to offer any theories as to why this fixes the problem, but here is what I now know.

Somewhere in this request path the response was being arbitrarily truncated by either bytes or characters.

Facebook canvas app >> Zerigo DNS add-on >> Cedar Stack / Gunicorn >> Django

I confirmed this by replacing the entire contents of my application with text from project gutenberg- and sure enough, the response would sporadically be truncated at the same character each time.

Cutting out Zerigo and pointing the Facebook canvas application directly to the application address on heroku (e.g http://quotewars.herokuapp.com/) seems to have solved the issue.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文