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.
Related
I'm trying to scrape data from a website but I have no experience with scraping or APIs except for making a Discord Bot once. So I followed the steps described here to find the API:
http://www.gregreda.com/2015/02/15/web-scraping-finding-the-api
The Request URL in the Headers tab with the important information is this one:
https://api.amiami.com/api/v1.0/item?gcode=FIGURE-119023&lang=eng
When I try to open this page, like he does, it only returns:
{"RSuccess":false,"RValue":{"HttpStatusCode":400},"RMessage":"Invalid access."}
If you want to try getting the Request URL yourself, the original page I used was:
https://www.amiami.com/eng/detail/?gcode=FIGURE-119023
Removing the language argument doesn't seem to change anything either. So I guess there's something that detects that I'm not accessing it in a normal way. Any Ideas on how to fix this?
Is there any setting for url limit in Yii 2?
Some of my urls are over 300 characters and I get a 403 Forbidden code;
http://website/servicii-de-proiectare-asistenta-tehnica-din-partea-proiectantului-pe-perioada-derularii-lucrarilor-si-executie-de-lucrari-pentru-proiectul-%E2%80%9Emodernizare-drumuri-comunale-dc----dc----si-dc---a-de-pe-raza-comunei-lunca-judetul-boto-ani%E2%80%9D-863506-switch.html
If I shorten the url, it works.
this is my urlmanager rule:
'<title:(.*)>-<id:([0-9]+)>-access-not-granted.html' => 'member/licitatii/access-not-granted',
I tried to find some information regarding this issue and surprisingly enough, I didn't found a thing regarding URL length permitted.
However, I found a Yii way to solve your issue: Short URL Yii extension presented here - http://www.yiiframework.com/extension/google-url-shortener/
Also, please read this documentation that better explains how Yii treats URL routs: http://www.larryullman.com/2013/02/18/understanding-routes-in-the-yii-framework/
I know this does not solve your problem directly, but hope it gets you somewhere!
L.E: Here you have the bitly extension for Short URL's: http://www.yiiframework.com/extension/bitly-url-shortener/
Keep on coding,
Ares.
Why would that rule apply to your URL? From what I can see your URL will never trigger that rule.
I do not think there is a limit with the string of the URL in Yii2, try deleting some of the first part of the string to test this. try with an url like
http://website/proiectul-%E2%80%9Emodernizare-drumuri-comunale-dc----dc----si-dc---a-de-pe-raza-comunei-lunca-judetul-boto-ani%E2%80%9D-863506-switch.html
You might have problems because you have diacritics in the URL, try without them.
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.
Let's say that I have a web app that responds to URLs in the format /entities/{entityKey}. In my access logs, I find people visiting both /entities/KEY1 which is how app URLs are generated, as well as the lower case version of /entities/key1. Currently key1 will throw a 404 not found error due to route requirements.
My question is, would you:
Use URL re-writing to re-write key to uppercase.
Create 302 redirects from lowercase to uppercase?
Have the application convert to uppercase and handle requests in a case-insensitive fashion
Most users these days expect URLs to be case-insensitive. I would have the app silently handle the conversion in the background. I don't see it being worth the extra request time to issue a redirect.
If SEO is a concern, then you can use the rel="canonical" meta tag to let google/other search engines know which URL you want to appear in search results.
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>