When i use the LinkedIn API to get profile information, the picture urls are sometime not accessible.
I get this response
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>403 - Forbidden</title>
</head>
<body>
<h1>403 - Forbidden</h1>
</body>
</html>
Upon further digging I find that LinkedIn returns something like this for original picture url
.../profile-originalphoto-shrink_900_1200...
However, when I go to LinkedIn.com and checkout the URL of the picture of the profile it looks something like this
.../profile-originalphoto-shrink_800_800...
Does anyone else face this issue? What is going on here?
I also verified that I'm using the correct scope "r_basicprofile"
Rather than requesting the original picture-url, you can make a request to a resized picture-url. For example,
picture-url;size=400
where size can be 100, 200, or 400.
I looked at the URL of my picture of my In Public profile and the one returned from the API.
The picture URL in the XML returned after the "?" for params v and t had "& ;" instead of "&":
e.g.
https://media.licdn.com/.../profile-displayphoto-shrink_200_200/0?e=152800"&";v=beta"&";t=LJTrw_oj9npH06X1u0HjQ
replacing it with sth like pictureURL = pictureURL.replaceAll("& ;","&"); fixed the issue for me. Hope this helps
note that the there is an extra space between & and ; it would have formatted otherwise.
Related
Oki, I got my head on the table here.
I'm trying to get contents from another page, and interact with it. Using some kind of advanced iframe solution.
Up until now I've been using the ugly iframe solution, you can see the results here :
http://www.mosfellsbaer.is/stjornkerfi/stjornkerfi/fundargerdir/
Please try to interact with it to see how ugly this is.
Ok..
I found another page that uses the same system as we do, but it looks a lot better.
It's an iframe, but when looking at the source code, I dont see any iframe embed code or anything that points to that it's an iframe. Here is the page :
http://www.kopavogur.is/stjornsyslan/fundargerdir/searchmeetings.aspx
But I know this is some kind of an iframe.
Their way is a bit better because they can use their own css and such.
Somehow they get the contents from the searchmeetings.aspx and post it to their page
How the h... are they doing this ?
I'm kind of new at this here
Thanks in advance
It's not an iframe... Looks like they're doing something like this: How to display an ASPX in another ASPX's DIV dynamically at runtime?
It's an ASP page, and the inserted document has a few clues telling us that it's a Microsoft generated page as well:
<div class="boxbody">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<HEAD>
<title>Leit í fundargerðum</title>
<meta name="GENERATOR" Content="Microsoft Visual Studio .NET 7.1">
<meta name="CODE_LANGUAGE" Content="C#">
<meta name="vs_defaultClientScript" content="JavaScript">
<meta name="vs_targetSchema" content="http://schemas.microsoft.com/intellisense/ie5">
<link href="css/fonts.css" rel="stylesheet" type="text/css">
</HEAD>
<body>
Rich text field value <div> </div>
output <div>?</div>
DWT:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
##Component.Fields.Text##
</html>
what did i miss?
thanks
I can't try it out now due to lack of time, but a few things come to mind:
What's the encoding set on your publication target?
Do you get the same result in Template Builder and Preview?
If you open the published file with a text editor like Notepad++, what does it show?
EDIT
In preview I get this:
<div> </div>
After publishing I get the same as you:
<div>?</div>
So I changed my publication target to use "Unicode (UTF-8)" instead of "System Default", and now when I publish I get this:
<div>Â </div>
I then referred to Elena's excellent 7 clues to deal with encoding, and figured out I was missing this on my web.config:
<globalization fileEncoding="UTF-8" requestEncoding="UTF-8" responseEncoding="UTF-8"/>
This still didn't do it, it was still loading this weird character in between the tags. This last clue was because the encoding was not being applied to pages with the ".html" extension. Renamed my page template to have a .aspx extension, published, pressed F5 and magic, my div now shows:
<div> </div>
EDIT 2 If you want to use the .html extension, just add this to your page's <head>:
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
When loading a page containing references to non-existing URL's using tags, I see a strange text reply from the server.
The server does return status code 404 as expected, but it also includes a text response with chinese-like characters.
Is the server infected, or is the error message just in a different language than english ... ?
If infected, how can I find out where?
Here is an example of the text replies. It seems that the reply is identical for each 404 error, although a part of it changes when a different filetype is not found.
㰡䑏䍔奐䔠桴浬⁐啂䱉䌠∭⼯圳䌯⽄呄⁘䡔䵌‱⸰⁓瑲楣琯⽅丢•桴瑰㨯⽷睷㌮潲术呒⽸桴浬ㄯ䑔䐯硨瑭氱瑲楣琮摴搢㸍਼桴浬⁸浬湳㴢桴瑰㨯⽷睷㌮潲术ㄹ㤹⽸桴浬∾ഊ㱨敡搾ഊ㱭整愠桴瑰ⵥ煵楶㴢䍯湴敮琭呹灥∠捯湴敮琽≴數琯桴浬㬠捨慲獥琽楳漭㠸㔹ⴱ∯㸍਼瑩瑬放㐰㐠ⴠ䙩汥爠摩牥捴潲礠湯琠景畮搮㰯瑩瑬放ഊ㱳瑹汥⁴祰攽≴數琯捳猢㸍਼ℭⴍ潤祻浡牧楮㨰㭦潮琭獩穥㨮㝥活景湴ⵦ慭楬示噥牤慮愬⁁物慬Ⱐ䡥汶整楣愬慮猭獥物昻...
You have a character encoding issue. It is a ASCII file that is being interpretted as a 2byte character encoding and thus you are getting the strange characters.
To translate it I copied the text to notepad. Saved it as Unicode-Big Endian and then used a hex editor to strip the first two characters (that tell it that it is unicode). Opening it again gave me:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>404 - File or directory not found.</title> <style type="text/css"> <!-- body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;
You would need to look into things to see if it is declaring the wrong content type in an HTML header (the content type in the meta tag looks correct) or something else is causing it problems.
Our app renders Like buttons that point back to an actual Facebook page. However, instead of pointing the Like button's href directly to the FB url, we proxy it through our servers through an opengraph endpoint. This is helpful because it allows us to have more detailed analytics on when these endpoints are used (amongst other things.) When these endpoints are hit with a user agent like 'facebookexternalhit', they render something like the following:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta property="fb:app_id" content="158708354177049" />
<meta property="og:site_name" content="BandPage" />
<meta property="og:url" content="http://www.facebook.com/stormystrongmusic" />
<meta property="og:type" content="band" />
<meta property="og:title" content="Stormy Strong" />
<meta property="og:description" content="..." />
<meta property="og:image" content="https://graph.facebook.com/20501829906/picture" />
<title>Stormy Strong</title>
<link rel="canonical" href="http://www.facebook.com/stormystrongmusic"/>
</head>
<body>
</body>
</html>
Note that both og:url and the link rel="canonical" point to the actual Facebook Page. In practice, this looks like it behaves fine when we try running the link through Facebook's debugger: https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fwww.bandpage-s.com%2Fogp%2F11601543111380992
However, there is a problem where, after an interval, the Like buttons appear to not resolve back to the page anymore. This results in the Like count being off, the button not being 'Liked' if you already like the page, etc. Manually triggering a re-scrape by going to the OG debugger url above solves the problem, for a time.
Obviously manually re-triggering these scrapes is not a tenable solution. Are there multiple scraper behaviors happening here? It seems like the scraper that is triggered w/ the debugger is different than the one that periodically re-scrapes automatically.
Why does this happen? Is there anything we can do to get around this, except for getting rid of our ogp endpoint 'middle-man' here? This seems like a perfect utilization of og:url.
In one of my asp.net-applications I found a strange behaviour produced in Internet Explorer 9 while IE8 works well.
As the default encoding I need utf-8. That's important because I use german so called Umlaute like "ÄäÖüÜü".
When the page is loaded for the first time IE9 decides to use "Western Europe" Encoding. That's ISO 8859-1 as far as I know and the Umlaute change to strange letters.
On the second load IE9 uses utf-8 correctly.
In the sourcecode I tried the following things to tell IE which encoding to use:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 TRANSITIONAL//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="de">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
Why does IE9 work so strange on the first load?
And what else can I try to tell IE9 how to work
Firstable - server where you host your site can return wrong encoding information in header;
Two - maybe it's some fail in string that tolk about encoding in the header of your page (wrong symbol in that string).
Three - open you page in Hex brouser (WinHex for example) and post first row of code (sometimes editor place wrong data in first byte, I've stumble on it once)
If this site is placed online, post it's url and I try to find a problem.
Check response header of you server it must contains something like this:
Key Value
Content-Type text/html; charset=utf-8
Response HTTP/1.1 200 OK
if it's not then check you server settings or you code there must be place where Content-type header changes
EDIT: ok, encoding is right, as suggested in the comment you shoul check first bytes of you response, it seems like it starts with additional bytes (usually info about encoding)