I saw some request like
www.example.com/start.php?404;http://www.example.com:80
but unfortunately can't understand if it is a valid url or how it will work.
www.example.com/start.php?404
and
http://www.example.com:80
and
www.example.com/start.php?404;http://www.example.com:80
are all valid URLs. But since ; is not a reserved symbol, it needs to be URL encoded. See Characters allowed in a URL for the list of characters allowed in a URL.
I don't think its a valid url. It redirects you to a 404 page. The http://www.example.com:80 is probably wrong set so it enters a complete url at the end of the already standing url.
Maybe i am wrong.
Related
I'm making an API, everything is handled inside the file, so here's what an example URL might look like.
https://website.com/api/?type=search&user=bob
And I'd want that to turn into
https://website.com/api/search/bob
But now here's the other part to this issue. I have another type, which is CSRF
https://website.com/api/?type=csrf
And that would be
https://website.com/api/csrf/
Note that it's one parameter short, but yet still working off the same file. Anything i've tried never seems to work correctly. Additionally there always seems to be a \ added to the api file. I've already removed the .php from there.
So when I try this it doesn't work. Any ideas?
rewrite ^/([a-zA-Z0-9_-]+)/([0-9]+)$ /api/?type=$1&user=$2;
Your problem seems to be that you use $2 for your username and this correspond to ([0-9]+) in your regular expression.
Which means, username will have to be numbers only.
Change your expression to :
rewrite ^/([a-zA-Z0-9\_\-]+)/([a-zA-Z0-9\_\-]+)$ /api/?type=$1&user=$2;
And your rules should work.
I'm trying to redirect the user back to a certain URL after a form submit with the following
header( "refresh:3;url=http://www.XXXX.XXXX/XXXXX/addshotstogamePart2.php?gameNo=$gameNo&roundName=$roundName" );
which should be something like this
http://XXXX.XXXX/XXXX/addshotstogamePart2.php?gameNo=24&roundName=Round+1
but what i'm getting is
http://XXX.XXX/XXX/addshotstogamePart2.php?gameNo=24&roundName=Round%25201
How can i avoid that or fix it?
It looks that Round+1 gets url encoded.
Because + is not a valid url symbol.
You can use other symbol, for example ...&roundName=Round_1
Or use just number ...&roundName=1
You can use no symbol at all ...&roundName=Round1 but then you need to parse that number out of string.
http://localhost/foo/profile/%26lt%3Bi%26gt%3Bmarco%26lt%3B%2Fi%26gt%3B
The url above gives me a 404 Error, the url code is this: urlencode(htmlspecialchars($foo));, as for the $foo: <i>badhtml</i>
The url works fine when there's nothing to encode e.g. marco.
Thanks. =D
Update: I'm supposed to capture the segment in the encoded part of the uri, so a 404 isn't supposed to appear.
There isn't any document there, marco is simply the string that I needed to fetch that person's info from db. If the user doesn't exist, it won't throw that ugly error anyways.
Slight idea what's wrong: I found out that if I used <i>badhtml<i>, it works just fine but <i>badhtml</i> won't, what do I do so that I can maintain the / in the <i>?
It probably think of the request as http://localhost/foo/profile/<i>badhtml<**/**i>
Since there is a slash / in the parameter, this is getting interpreted as a path name separator.
The solution, therefore, is to replace all occurrences of a slash with something that doesn't get interpreted as a separator. \u2044 or something. And when reading the parameter back in, change all \u2044s back to normal slashes.
(I chose \u2044 because this character looks remarkably like a normal slash, but you can use anthing that would never occur in the parameter, of course.)
It is most likely that the regex responsible for handling the URL rewrite does not like some of the characters in the URL-encoded string. This is most likely httpd/apache question, rather than PHP. Your best guess is to start by looking at the .htaccess (file containing URL rewrite rules).
This question assumes that your are trying to pass an argument through the URL, rather than access a file named <i>badhtml</i>.
Mr. Lister, you rocked.
"The solution, therefore, is to replace all occurrences of a slash with something that doesn't get interpreted as a separator. \u2044 or something. And when reading the parameter back in, change all \u2044s back to normal slashes."
Here's the thing. I have friendly urls like
http://site.com/blog/read/мъдростта-на-вековете
http://site.com/blog/read/green-apple
The last segment is actually the friendly title of the blog article. The problem is when I try to pass that segment to the database, the cyrillic fonts turn into something like %D1%8A%D0%B4%D1%80%D0%BE%D1%81%D1%8 and couldn't match the database record. In the address bar in my browser it looks normal (мъдростта-на-вековете) but if I choose 'copy url location' the last segment again turns into these strange characters. I'm using CodeIgniter and everything is set to UTF-8.
Please help! :(
The text is just being encoded to fit the specification for URLs.
Echo out the data to a log to see what you are actually trying to pass to the database.
You should be able to decode it with urldecode.
The above answers are ok, but if you want to use routing with cyrillic it isn't enough. For example if you have http://site.com/блог/статия/мъдростта-на-вековете you will have to do something like this:
In config/routes.php: $route['блог/статия/(:any)'] = "blog/article/$1";
In system/core/URI.php , in the function _explode_segments(), you can change
$val = trim($this->_filter_uri($val));
to
$val = urldecode(trim($this->_filter_uri($val)));
This will solve the above problem plus controllers and functions.
Actually, Firefox is cheating you here: the URL actually is url-encoded, but is shown as if it wasn't. So copy-pasting and retrieving it on the server will have the URL encoded.
(Not sure if other browsers behave in the same way.)
I'm trying to understand how I should work with characters in URLs, this because I'm building a site where the user can store content and go to the content's page by digiting it's name in the URL.
so, something like Wikipedia or Last.FM website.
I see in the site, user can write something likehttp://it.wikipedia.org/wiki/Trentemøller and the page of the artist can reached.
after the page is loaded, if I copy the URL i see written as:http://it.wikipedia.org/wiki/Trentemøller but if I paste it into a text editor, it will be pasted as
http://it.wikipedia.org/wiki/Trentem%C3%B8ller
so the char ø is pasted as %C3%B8
of course the same is for URLs like this (the page of the artist Takeshi Kobayashi)
http://www.last.fm/music/小林武史
http://www.last.fm/music/%E5%B0%8F%E6%9E%97%E6%AD%A6%E5%8F%B2
If I digit the first or the second, the page works in any case, why?
I think I should do something with the .htacces and mod_rewrite but I'm not sure, are the special chars automatically converted to the url special chars?
and then, how can I do to let PHP do the right query with the content name?
if I have a table like
table_users
- username
- age
- height
- weight
- sex
- email
- country
I'm able with mod_rewrite to write an address like http://mysite.com/user/bob to get the username bob from the table_users but what about http://mysite.com/user/小林武史?
here I show a simple example of what I think to do:
#.htaccess
RewriteEngine On
RewriteRule ^(user/)([a-zA-Z0-9_+-]+)([/]?)$ user.php?username=$2
<?php
// this is the page user.php
// this is the way I use to get the url value
print $_REQUEST["username"];
?>
this works, but it's limited to [a-zA-Z0-9_+-], how to be more compatible with all chars like the others without loss too much security?
Did someone know some way to avoid troubles?
Try urlencode and urldecode
Edit :
Here is Visualy the Description of url encoding and decoding
http://blog.neraliu.com/wp-content/uploads/2009/10/url-encoding.png
Most browsers urlencode() 小林武史 to %E5%B0%8F%E6%9E%97%E6%AD%A6%E5%8F%B2.
Reguarding your .htaccess mod_rewrite rules, have you considered using something like:
RewriteEngine On
RewriteRule ^(user/)(.+?)[/]?$ user.php?username=$2
As far as I understand every URL with not ASCII characters is mapped to unique ASCII based url. This is actually a feature on the client side. Please look at: http://kmeleon.sourceforge.net/bugs/viewbug.php?bugid=631 to see examples and link to RFCs coverting this one.