FB doesn't seem to respect ACCEPT headers sent to /feeds/page.php. See below example:
GET /feeds/page.php?id=10036618151&format=rss20 HTTP/1.1
Connection: Keep-Alive
**Accept: text/xml,application/xml**
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)
Host: www.facebook.com
HTTP/1.1 200 OK
Cache-Control: private, no-cache, no-store, must-revalidate
**Content-type: application/rss+xml**
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Last-Modified: Wed, 08 Feb 2012 10:05:49 -0800
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
Pragma: no-cache
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Set-Cookie: datr=-vIzT4cxw52hjjqTfrpQkNYX; expires=Sat, 08-Feb-2014 16:23:22 GMT;path=/; domain=.facebook.com; httponly
X-FB-Debug: qx/SiyRZDiVPm4wfiKVj37HImPoKM+DVAsO4oKSbSr0=
X-Cnection: close
Date: Thu, 09 Feb 2012 16:23:22 GMT
Content-Length: 41236
I cannot seem to find a way to post a new bug report on http://developers.facebook.com/bugs, as I don't have the "Create" (nor the "Subscribe") buttons as described here http://developers.facebook.com/blog/post/559/
I have read that there are a fair few FB developers involved with this site, and was hoping that someone could shed some light on what I might be doing wrong / how to request FB changes the code to respect my request, or 406 me.
You are going to want to verify yourself as a developer in order to create a bug.
Check out this link for verification via -
mobile number
credit card
Once you have verified your account, head back to the bug system.
Related
We recently started using Azure CDN however some users reported an issue and we got a screenshot from one of them:
:
We were not able to get any more information on the issue. Any idea what could cause this and how to fix it?
Our origin server returns correctly the file with the following response headers:
Accept-Ranges: bytes
Access-Control-Allow-Origin: https://www.google.com
Cache-Control: max-age=31536000
Content-Encoding: gzip
Content-Length: 1956119
Content-Type: text/css
Date: Tue, 16 Feb 2021 18:44:10 GMT
ETag: "011889dd7ffd61:0"
Expect-CT: max-age=604800, enforce,
Feature-Policy: autoplay 'none'; camera 'none'
Last-Modified: Wed, 10 Feb 2021 18:07:38 GMT
strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
I got a similar problem. I was able to fix this by enabling cache i Dev Tools.
Enable cahce in Dev Tools
Every article on the following website fails when attempting to share the page via the share link in our social media widget.
for example:
the following page, http://news.gc.ca/web/article-en.do?mthd=index&crtr.page=1&nid=957389 when shared via the following link:
Returns an Error: Connection error in the share preview window. Response headers for this request are:
Cache-Control: private, no-cache, no-store, must-revalidate
Content-Encoding: gzip
Content-Type: text/html
Date: Wed, 01 Apr 2015 14:22:20 GMT
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Pragma: no-cache
Strict-Transport-Security: max-age=15552000; preload
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-FB-Debug: iYvCJSRJJqVdVXyIubD1kVq6teZBILIBRrCACZW9hI/Ms+B2qsquq52KyU5820UTfLmuXTis3LbRoL2bMlCVBw==
X-Frame-Options: DENY
X-XSS-Protection: 0
X-Firefox-Spdy: 3.1
200 OK
running the above URL through the OpenGraph object debugger returns:
Error parsing input URL, no data was cached, or no data was scraped.
and the scraper sees the following for the URL:
Document returned no data
We need to determine the cause of this since none of our content can be shared from our site at the moment.
Any ideas, tips greatly appreciated!
Background info: Some of my website innerpages had malware on it last week. The whole site has been reset, updated en cleared from malware a couple days ago. The website is SE optimized, but not spammed at all.
Q: Some innerpages of the website have suddenly dropped from the Google results.
Searching site: http://www.domain.com/innerpage doesn't even give a result.
Searching cache: http://www.domain.com/innerpage has no results since today
Webmaster page error: The page seems to redirect to itself. This may result in an infinite redirect loop. Please check the Help Center article about redirects.
HTTP/1.1 301 Moved Permanently
Date: Mon, 28 Oct 2013 20:15:18 GMT
Server: Apache
X-Powered-By: PHP/5.3.21
Set-Cookie: PHPSESSID=170fc3f0740f2eb26ed661493992843a; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Pingback: http://www.domain.com/xmlrpc.php
Location: http://www.domain.com/innerpage/
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
The .htaccess file looks fine too. Do you guys have any idea what going on here?
The page is w3c valid and even online googlebot simulators show state 200 OK.
I was using the PalPal IPN simulator all day without problems, and at some point I got kicked out and the developer portal got upgrade.
Picking up right where I left off, I'm now receiving IPN messages from the sandbox, but attempts to validate the message return 400 Bad Request.
Now before you go saying "Oh, you just need to do HTTP/1.1 and send the Host:" field, I'm already doing that (and have been for months).
Request body:
POST /cgi-bin/webscr HTTP/1.1
Host: www.sandbox.paypal.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 1008
Connection: Close
Response body:
HTTP/1.1 400 Bad Request
Date: Sat, 09 Mar 2013 00:07:26 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
Set-Cookie: c9MWDuvPtT9GIMyPc3jwol1VSlO=%7chl7gnTEYtJzNIfLXr3W6GtWjMBrl6ln8aFetxEss8pSDsWPDwv59RMYj7ONKH0013betZW%7cnf1wC_g4C0pER3V0XtOw2969OSDVwC24TgW3akpoK6QHdkz0_7G0YdJ9Cnjz-JKZbESVG0%7c; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: cookie_check=yes; expires=Tue, 07-Mar-2023 00:07:26 GMT; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: Apache=10.72.109.11.1362787646017906; path=/; expires=Mon, 02-Mar-43 00:07:26 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain; charset=ISO-8859-1
It it just me, or is the portal broken?
You're correct. The ability to verify IPNs in sandbox is broken at the moment. We're currently working to fix the issue now and I'll be sure to update you once we have an update.
Please let me know if you are experiencing any other issues with the developer/sandbox environment and I'll be sure to follow up.
I am programmatically creating test accounts, and then immediately trying to log in w/ them using a selenium driven browser. Unfortunately, the browser is just redirected to the facebook homepage. I can briefly see what appears to be the correct url prior to the redirect flash by, so I have no reason to believe the browser isn't going where I intend it to.
That said, if create a fake account, and then just paste the login_url into a browser, things work fine. Anyone have any idea why that might be unique about using Selenium here? Is there anything I need to do to prepare the browser for https connections or anything?
All I'm doing is this: (using capybara and the Selenium web driver)
visit #fake_user.login_url
https://www.facebook.com/platform/test_account_login.php?user_id=100002152974488&n=ILRvb8Lqf2cq05t
GET /platform/test_account_login.php?user_id=100002152974488&n=ILRvb8Lqf2cq05t HTTP/1.1
Host: www.facebook.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
HTTP/1.1 302 Found
Cache-Control: private, no-cache, no-store, must-revalidate
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location: http://www.facebook.com/
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
Pragma: no-cache
Set-Cookie: datr=d3J_TWSAN5uIXyh94O1YJkJ8; expires=Thu, 14-Mar-2013 14:06:47 GMT; path=/; domain=.facebook.com; httponly
Set-Cookie: lsd=-Lv-N; path=/; domain=.facebook.com
Content-Type: text/html; charset=utf-8
X-Powered-By: HPHP
X-FB-Server: 10.52.145.67
X-Cnection: close
Date: Tue, 15 Mar 2011 14:06:47 GMT
Content-Length: 0
http://www.facebook.com/
GET / HTTP/1.1
Host: www.facebook.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: datr=d3J_TWSAN5uIXyh94O1YJkJ8; lsd=-Lv-N
HTTP/1.1 200 OK
Cache-Control: private, no-cache, no-store, must-revalidate
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
Pragma: no-cache
Set-Cookie: reg_fb_gate=http%3A%2F%2Fwww.facebook.com%2F; path=/; domain=.facebook.com
Set-Cookie: reg_fb_ref=http%3A%2F%2Fwww.facebook.com%2F; path=/; domain=.facebook.com
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Powered-By: HPHP
X-FB-Server: 10.52.163.25
X-Cnection: close
Transfer-Encoding: chunked
Date: Tue, 15 Mar 2011 14:06:47 GMT
Visit Facebook home page before trying to visit login url:
visit "https://www.facebook.com"
visit #fake_user.login_url
I haven't checked the headers, but I guess Facebook sets some cookies that are needed to log in.