Home/ Questions/Q 8128607
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T07:57:01+00:00

I have an extremely simple page that I’m trying to view in the Facebook

  • 0

I have an extremely simple page that I’m trying to view in the Facebook iframe. It’s a Django-view but it’s not dependent upon whether the request is submitted via POST or GET. All it does is returns some simple HTML.

If we hit the link directly, it displays correctly. If, in firefox, I right-click on the iframe and choose the option to display only that frame — then it shows correctly. However, when viewing the Facebook App, nothing shows up.

Here’s the App Link: http://apps.facebook.com/fireflietest/
Which points to http://www.fireflie.com/facebook/

Here’s the code for my very simple view:

from django.http import HttpResponse
from django.views.decorators.csrf import csrf_exempt, csrf_protect

@csrf_exempt
def facebook(request):
    body = """
    <html>
        <head><title>Fireflie on Facebook</title></head>
        <body>Hello, Facebook!</body>
    </html>
    """
    return HttpResponse(body)

Just for testing purposes, I created a small HTML form that would POST to that page. It works fine. I also ran the Facebook debugging tool and the “scraper” showed that it’s pulling our content correctly.

Here’s the server logs showing that it is returning a 200 OK both times:

24.210.144.32 - - [15/Jun/2012:18:27:18 +0000] "POST /facebook/ HTTP/1.1" 200 31 "http://apps.facebook.com/fireflietest/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19"

24.210.144.32 - - [15/Jun/2012:18:27:26 +0000] "GET /facebook/ HTTP/1.1" 200 67 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19"

Finally, I tried digging into the response object using Chrome’s developer tools but it looks like all that is being returned, when viewing the iframe version, is the content headers.

Does anybody have any idea on what’s going on here? Or any ideas on how to futher debug this problem? Thanks.

Edit: I copied and pasted the Facebook App’s URL into the same spot. I’m going to duplicate it here again just in case I did something wrong. I’m not sure why it was throwing a 404.

Copied and pasted straight from the address bar: http://apps.facebook.com/fireflietest/

Update: Turns out I had to turn of Sandbox mode. There shouldn’t be any more 404. Of course, I’m still running into the original problem which is my iFrame showing up empty. Thanks!

Update 2: (Copied & Pasted from my Django User Group thead)

I’ve been trying to diagnose this problem. I have no idea what’s going on, though.

  1. I tried just serving a simple .html page on Nginx to see if that’s where the problem was. It didn’t serve properly (through an error) but it did actually display the error. The problem there was, you can’t POST to static pages in NGINX. No big deal, I’m not trying to load a static page anyways.

  2. I looked in my log files. It turns out, my application is timing out. It doesn’t make any sense as it doesn’t timeout anywhere else.

  3. Here’s some logs that show something peculiar going on. I’m not sure how to debug the issue. From what I am reading though — here’s what I picture is going on.

Nginx properly receives request. Nginx pushes request to uWSGI application (django). Django successfully gets the request. Django tries to respond but this must be where it breaks.

I’m not sure what the issue is — but it has something to do with being inside a facebook iframe. (I have yet to check remote iframes in general, I’ll do that next)

uWSGI Logs:
[pid: 11059|app: 0|req: 3/4] 24.210.144.32 () {52 vars in 1170 bytes} [Tue Jun 19            14:24:03 2012] POST /facebook/ => generated 0 bytes in 444 msecs (HTTP/1.1 500) 0 headers in 0 bytes (0 switches on core 0)
[pid: 11345|app: 0|req: 1/1] 24.210.144.32 () {52 vars in 1170 bytes} [Tue Jun 19 14:24:31 2012] POST /facebook/ => generated 2970 bytes in 333 msecs (HTTP/1.1 200) 4 headers in 128 bytes (1 switches on core 0)
[pid: 11353|app: 0|req: 3/31] 24.210.144.32 () {52 vars in 1172 bytes} [Tue Jun 19 14:31:04 2012] POST /facebook/ => generated 2970 bytes in 3 msecs (HTTP/1.1 200) 4 headers in 128 bytes (1 switches on core 0)
[pid: 11954|app: 0|req: 1/14] 24.210.144.32 () {52 vars in 1216 bytes} [Tue Jun 19 14:35:04 2012] POST /facebook/ => generated 2970 bytes in 343 msecs (HTTP/1.1 200) 4 headers in 128 bytes (1 switches on core 0)
[pid: 11950|app: 0|req: 2/31] 24.210.144.32 () {52 vars in 1211 bytes} [Tue Jun 19 14:48:57 2012] POST /facebook/ => generated 2970 bytes in 3 msecs (HTTP/1.1 200) 4 headers in 128 bytes (1 switches on core 0)
[pid: 11962|app: 0|req: 4/57] 24.210.144.32 () {52 vars in 1216 bytes} [Tue Jun 19 14:53:43 2012] POST /facebook/ => generated 2970 bytes in 2 msecs (HTTP/1.1 200) 4 headers in 128 bytes (1 switches on core 0)

Nginx Error Logs:
2012/06/19 20:02:30 [error] 11164#0: *29617 readv() failed (104: Connection reset by peer) while reading upstream, client: 24.210.144.32, server: fireflie.com, request: "POST /facebook/ HTTP/1.1", upstream: "uwsgi://<commented out for security>", host:     "www.fireflie.com", referrer: "http://apps.facebook.com/253156011452899/"

Nginx Access Log:
24.210.144.32 - - [19/Jun/2012:20:02:30 +0000] "POST /facebook/ HTTP/1.1" 200 31 "http://apps.facebook.com/253156011452899/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19"
24.210.144.32 - - [19/Jun/2012:20:03:29 +0000] "-" 408 0 "-" "-"
24.210.144.32 - - [19/Jun/2012:20:03:29 +0000] "-" 408 0 "-" "-"
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Solution

    The problem was with uWSGI. I’m not exactly sure why it wasn’t working — but I believe it might have been something to do with Facebook’s Canvas App POSTing too small of data. Anyways, here’s the fix that worked for me.

    I modified my uWSGI configuration options. I added the following three options even though the first might be a no-op and the last is probably just there for good safety (it works on my staging site without it).

    <pep3333-input/>
<post-buffering>4096</post-buffering>
<buffer-size>32768</buffer-size>
    • 0