Any clue why Facebook iframe would be blank?

Kurtis Mullins

unread,

Jun 15, 2012, 1:40:25 PM6/15/12

to django...@googlegroups.com

I've created a very simple page. It pretty much just dumps out some html with the text "Hello, Facebook". This view can be found at: http://www.fireflie.com/facebook/

We created a very simple Canvas app on facebook pointing to this link. It can be found here: http://apps.facebook.com/fireflietest/

For some odd reason, when I hit the view directly it prints out the text without any problem. I can do a GET or POST request and get the same results. However, when I view the Facebook app -- it shows nothing. It's just blank. On the contrary, if I point it at other URLs which actually have some real functionality and aren't CSRF Excempt -- then they show the error page. But it's still some type of output.

I've used Google Chrome and Firebug to try to see the response object from my site. It looks like only the headers are being returned. Am I missing something obvious? haha

Here's the tiny little view that I'm using:

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)

I looked through my nginx logs and saw these lines which are kind of weird:

24.210.144.32 - fireflie [15/Jun/2012:17:09:34 +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:17:09:50 +0000] "-" 400 0 "-" "-"

24.210.144.32 - fireflie [15/Jun/2012:17:10:05 +0000] "GET /facebook/ HTTP/1.1" 200 111 "-" "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"

The first several lines are from my connection attempt using Facebook. The last line is directly hitting the server. In this particular case I did use two different browsers but I've tried it every browser I have.

I'm up for any ideas people might have on debugging this problem. Thanks!

Rafał Stożek

unread,

Jun 15, 2012, 1:56:56 PM6/15/12

to django...@googlegroups.com

Does this view accept POST requests? Because facebook uses POST to send you some data in signed_request param.

Rafał Stożek

unread,

Jun 15, 2012, 1:58:03 PM6/15/12

to django...@googlegroups.com

Sorry, I didn't read the code.

Kurtis Mullins

unread,

Jun 15, 2012, 2:33:27 PM6/15/12

to django...@googlegroups.com

Haha, no problem! Yep, it's in there (like you saw).

I opened up a Stackoverflow post with the question here: http://facebook.stackoverflow.com/questions/11056283/iframe-showing-up-blank

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/WB4GxsbA_QgJ.

To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Kurtis

unread,

Jun 19, 2012, 4:03:36 PM6/19/12

to django...@googlegroups.com

*Bump*

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 "-" "-"

Does anyone have an idea on how to further debug this issue? Thanks!

Gabriel - Iulian Dumbrava

unread,

Jun 22, 2012, 3:59:35 AM6/22/12

to django...@googlegroups.com

Hi,

I think something similar happen to me when I set the width of the iframe to be too narrow. I'm not very sure, but maybe you cand check it out.

Gabriel

Kurtis Mullins

unread,

Jun 22, 2012, 10:15:55 AM6/22/12

to django...@googlegroups.com

On Fri, Jun 22, 2012 at 3:59 AM, Gabriel - Iulian Dumbrava <gabriel....@gmail.com> wrote:

Hi,
I think something similar happen to me when I set the width of the iframe to be too narrow. I'm not very sure, but maybe you cand check it out.

Gabriel

Hey Garbiel,

I actually figured out the issue on my end. From what I gather, uWSGI doesn't handle small POST data sizes well. I had to change a couple of uWSGI configuration parameters (as seen on Stackoverflow).

As far as I can tell -- my stuff is all good now, both in the Fluid and fixed-size layouts.

If you need any help debugging yours, let me know! And thanks for the feedback.

- Kurtis Mullins

Roberto De Ioris

unread,

Jun 23, 2012, 10:43:15 AM6/23/12

to django...@googlegroups.com

This is a common problem in all of the proxied setup:

http://flask.pocoo.org/snippets/47/

The real fix is always reading POST datas when they are available (even if
you are not interested in them). Not reading them means your communication
socket with the webserver will be clobbered soon or later.

If you do not want to change your code you can use the uWSGI
--post-buffering option that will automatically buffer post data in memory
(or to disk).

--
Roberto De Ioris
http://unbit.it

Kurtis Mullins

unread,

Jun 23, 2012, 7:35:55 PM6/23/12

to django...@googlegroups.com

This is a common problem in all of the proxied setup:

http://flask.pocoo.org/snippets/47/

The real fix is always reading POST datas when they are available (even if
you are not interested in them). Not reading them means your communication
socket with the webserver will be clobbered soon or later.

If you do not want to change your code you can use the uWSGI
--post-buffering option that will automatically buffer post data in memory
(or to disk).

Thanks! I've never ran into this problem before but you definitely brought some light on the subject. I appreciate the good information!

Reply all

Reply to author

Forward