Trying to add a sharing function to my site, but GPlus seems to have trouble sharing url's with spaces in them.
Even escaped they dont seem to work.
eg;
https://plus.google.com/share?url=http://www.google.com/%23test%20test
It only seems to recognize upto before the %20.
Any ideas? Is this a bug? Am I doing something wrong?
The site is rather ajaxy, and in the history tokens would be a pain to need to use non-standard escaping of characters just for google plus.
I don't think that this is a bug with Google+ but rather its likely intentional because those URLs would need to be double URL encoded because one URL is sharing a second URL, thus your shared URL should be http%3A%2F%2Fwww.google.com%2F%2523test%2Btest
This won't work to create a preview in the share snippet but the URL is correct when it is shared.
All said, you shouldn't use spaces in your URLs because they are considered unsafe, see RFC 1738. You should change your app's URL structure.
Related
Is it bad practice to make a page that has a web address like these:
http://example.com/-products-and-services.php
http://example.com/-contact-us.php
http://example.com/--books.php
http://example.com/--translation.php
http://example.com/--illustration.php
http://example.com/-$-special-feature.php
http://example.com/-$-vip-area.php
Will google or apache have problems with these (- $) characters?
I am doing this because I makes it easier for me to view and categorise pages while still letting me add keywords to the file names.
Thanks
You can use alphanumerics, and the special characters "$-_.+!*'()," in url.
But it may not be very helpful with seo, search engine indexing etc.
You can read what google says here,
https://support.google.com/webmasters/answer/76329?hl=en
I have a page tab app that I am hosting. I have both http and https supported. While I receive a signed_request package as expected, after I decode it does not contain page information. That data is simply missing.
I verified that like schemes are being used (https) among facebook, my hosted site and even the 'go between'-- facebook's static page handler.
Also created a new application with page tab support but got the same results-- simply no page information in the signed_request.
Any other causes people can think of?
I add the app to the page tab using this link:
https://www.facebook.com/dialog/pagetab?app_id=176236832519816&next=https://www.intelligantt.com/Facebook/application.html
Here is the page tab I am using (Note: requires permissions):
https://www.facebook.com/pages/School-Auction-Test-2/154869721351873?id=154869721351873&sk=app_176236832519816
Here is the decoded signed_request I am receiving:
{"algorithm":"HMAC-SHA256","code":!REMOVED!,"issued_at":1369384264,"user_id":"1218470256"}
5/25 Update - I thought maybe the canvas app urls didn't match the page tab urls so I spent several hours going through scenarios where they both had a trailing slash or not. Where they both had a trailing ? or not, with query parameters or not.
I also tried changing the 'next' value when creating the page tab to the canvas app url and the page tab url.
No success on either count.
I did read where because I'm seeing the 'code' value in the signed_request it means Facebook either couldn't match my urls or that I'm capturing the second request. However, I given all the URL permutations I went through I believe the urls match. I also subscribed to the 'auth.authResponseChange' which should give me the very first authResponse that should contain the signed_request with page.id in it (but doesn't).
If I had any reputation, I'd add a bounty to this.
Thanks.
I've just spent ~5 hours on this exact same problem and posted a prior answer that was incorrect. Here's the deal:
As you pointed out, signed_request appears to be missing the page data if your tab is implemented in pure javascript as a static html page (with *.htm extension).
I repeated the exact same test, on the exact same page, but wrapped my html page (including js) within a Perl script (with *.cgi extension)... and voila, signed_request has the page info.
Although confusing (and should be better documented as a design choice by Facebook), this may make some sense because it would be impossible to validate the signed_request wholly within Javascript without placing your secretkey within the scope (and therefore revealing it to a potential hacker).
It would be much easier with the PHP SDK, but if you just want to use JavaScript, maybe this will help:
Facebook Registration - Reading the data/signed request with Javascript
Also, you may want to check out this: https://github.com/diulama/js-facebook-signed-request
simply you can't get the full params with the javascript signed_request, use the php sdk to get the full signed_request . and record the values you need into javascript variabls ...
with the php sdk after instanciation ... use the facebook object as following.
$signed_request = $facebook->getSignedRequest();
var_dump($signed_request) ;
this is just to debug but u'll see that the printed array will contain many values that u won't get with js sdk for security reasons.
hope that helped better anyone who would need it, cz it seems this issue takes at the min 3 hours for everyone who runs into.
As an example, the Rails parameterize method would create a string like so:
"hello-there-joe-smith" == "Hello There Joe.Smith".parameterize
For legacy reasons, a project I am working on requires uppercase letters as well as periods to be available in a particular URL parameter.
Why would this ever be a problem?
Clarification
The url type I'm talking about is what is used instead of an id, commonly knows as a slug.
Would a Rails app with the following url come to any issues: http://example.com/Smith.Joe?
This will be a problem both in terms of SEO and browser caching (and hence performance,)
Search engines are case sensitive, so same URL in different case will be taken as two URLs.
Browser like IE's caching is case sensitive, so eg. if you try to access your page as MYPAGE.aspx and at some place in code, you write it as mypage.aspx then IE will treat them as two different pages and instead of getting it from cahce, it will get it from server.
Dashes should be fine but underscores should be avoided : http://www.mattcutts.com/blog/dashes-vs-underscores/
It looks as though this question has been asked in part by some others, but I can't find the answer I'm looking for specifically, so I thought I'd pose my particular scenario in case anyone is able to help.
We have an old website (developed externally by a third party) that is due to be retired and replaced by a new site designed in house. For reasons best known to themselves, the developers of the old site used the hash character as part of the URL for the old site (www.mysite.com/#/my-content-stuff). To assist with the transition and help with SEO I need to set up 301 redirects for the top performing URLs from the old site. As I'm now discovering however, I'm not able to set up a simple redirect in the .htaccess file as I believe it takes the hash character to be a comment and ignores the remainder of the line. I've tried escape characters, using %23 instead, wildcard matching, nothing seems to work.
As a workaround, I wondered about simply creating dummy files with the same paths and URLs as the old site had, then simply creating HTML redirects within them to drive traffic to the correct new pages, but it looks as though the server is doing something similar regarding the hash character in the URL, and ignoring anything afterit. So, if I create a sub-folder on my news server called '#' and create a file in there called 'test.html', I expected to be able to just go to 'www.myNEWsite.com/#/test.html', but it just takes me to the default root file of my site.
Please can anyone shed any light on how I might get around this? I must admit I'm not that clued up on Apache so I'm having to learn a lot as I go.
Many thanks in advance for any pointers or info anyone can provide.
Cheers,
Rich
A hash character in the URL specifies the anchor, and it's not even sent to your webserver. A redirect is impossible on the server side, and the old developer probably did it using JavaScript. Implement fallback URLs without the hash instead, and have a global JavaScript script detect these URLs and redirect automatically.
Hash tags cannot be read by the server. They are regarded as locations within the document and are therefore not exposed to the server. The client is the only one whom see's these. The best you could do is use a "meta refresh" tag, or alternatively, you could use javascript to detect the url, and if its one which requires 301 redirection, use "window.location" to move the user to a full url where mod_rewrite or a php page can issue a 301 header.
However neither are SEO friendly and only really solve the issue for users that click onto an old link via an external site
<!-- Put in head tag so the page does not wait to load the content-->
<script type="text/javascript">
if(window.location.hash != "") {
var h = window.location.hash.match(/#\/?(.*)/i)[1];
switch(h) {
case "something_old":
window.location = "/something_new.html";
break;
case "something_also_old":
window.location = "/something_also_new.html";
break;
}
}
</script>
So, i have an url - http://somesite.com/#sometext. I need to shorten this url with the bit.ly API. The problem is, i cant properly escape the '#' symbol. I dont get any short url's if trying to short this one with the API. But i can simply short any other url's (without the '#').
The thing is i can properly shorten this url on bit.ly website and in TweetDeck (they using the API too, right?). But i cant manage to shorten it with the API.
Some suggestions?
Thanks you.
You can escape the URL fragment (#something) before sending it to bit.ly for shortening. URL fragment by definition won't leave the browser when submitted to the server. Escaping it allows it to go through. E.g. in Javascript, escUrl = encodeURIComponent(url) would do it.