Does Zend Framework hijack the raw $_GET and remove chars? I can't figure out whats going on with a script I am writing.
right now I am passing a variable "email" via a param in the url. Which its working, however. Its stripping out a character and leaving a space.
trying it like $_GET['email'] or like $params = $this->getRequest()->getParams(); $params['email'] on an email string that has a + in it the + gets removed and is replaced with a space. Yet I'm not applying anything that would cause that, that I am aware of anywhere.
So, does anyone else know what the issue may be?
Php does that, see this question:
When to encode space to plus (+) or %20?
To get a "+" use %2B in the url
Related
I have seen plenty of people having this problem and it seems the only way to stop apache treating the encoded ampersand and a URL ampersand is it use the mod rewrite B flag, RewriteRule ^(.*)$ index.php?path=$1 [L,QSA,B].
However, this isn't available in earlier versions of apache and has to be installed which is also not supported by some hosting companies.
I have found a solution that works well for us. We have a url of /search/results/Takeaway+Foods/Inverchorachan,+Argyll+&+Bute+
This obviously breaks the url at & giving us /search/results/Takeaway+Foods/Inverchorachan,+Argyll which then gives a 404 error as there is no such page.
The url is held in the $_GET['url'] array. If it finds an & the it splits the array for each ampersand.
The following code pieces the URL back together by traversing the $_GET array for each piece.
I would like to know if this has any hidden problems that I may not be aware of.
The code:
$newurl = "";
foreach($_GET as $key=>$pcs) {
if($newurl=="")
$newurl = $pcs;
else
$newurl .= "& ".rtrim($key,"_");
}
//echo $newurl;exit;
if($newurl!='') $url=$newurl;
I am trimming the underscore from the piece as apache added this. Not sure why but any help on this would be great.
You said in a cooment:
We want the URL to show the ampersand so substituting with other characters is not an option.
Short answer: Don't do it.
Seriously, don't use ampersands this way in URLs. Even if looks pretty. Ampersands have a special meaning in a URL and trying to override that meaning because it looks nice is a very bad idea.
Most web-based software (including Apache, PHP and all browsers) makes assumptions about what an ampersand means in a URL, which you will find very hard to work around.
In particular, you will utterly confuse Google and other search engines if you've got arbitrary ampersands in the URL, so it will completely destroy your SEO rank.
If you must have an ampersand in the string, use urlencoding to turn it into a URL-friendly %26. This won't look good in the user's URL string, but it will work as intended.
If that's not acceptable, then substitute something different for ampersands; maybe the word "and", or a character like and underscore, or perhaps just remove it from the string without a replacement.
All of these are common practice. Trying to force the URL to have an actual ampersand character in it is not common practice, and for very good reason.
Take a look at urlencode :
You can also replace the "&" char with something not breaking the URI and won't be interpreted by apache like the "|" char.
We have had this fix in place for two weeks now so I believe that this has solved the issue. I hope this will help someone with a similar issue as I searched for weeks for a solution outside of an apache upgrade to include the B flag. Our users can now type in Bed & Breakfast and we can then serve the appropriate page.
Here is the fix in PHP.
$newurl = "";
foreach($_GET as $key=>$pcs)
{
if($newurl=="")
$newurl = $pcs;
else
$newurl .= "& ".rtrim($key,"_");
}
if($newurl!='') $url=$newurl;
I've got this simple question... If you've got spaces in the URL $_GET, lets say
"page=about us", and if you then use this code IF($_GET['page']=='about us'). Would that work? Or do you have to use IF($_GET['page']=='about%20us')?
Thanks for your time!
Your browser converts the literal space in URLs into a + sign - before sending a HTTP request. When PHP sees that very + sign, it will become a space again for $_GET.
So, yes, it will work when comparing it against == "about us". Don't compare against the %20. (That's a valid, but unlikely encoding in URLs anyway.)
Sidenode. It's best not to rely on browser magic. When outputting the link, embed the + in place of spaces yourself.
Look at url_decode.
In my code, I create a link like this:
$link = 'http://www.mydomain.com/'.urlencode($str).'/1';
I use url-rewriting and the rule in my htaccess file looks like this:
rewriteRule ^(.+)/(.*)$ index.php?var1=$1&var2=$2 [NC,L]
This code is working fine for almost every strings. But sometimes, the string to encode contains "&". The urlencode function encodes it corectly, but when I read the $_GET array in php, it looks like this (with $str = 'substring1&substring2'):
'var1' => 'substring1' (without "&")
'substring2' => '' (without "&")
'var2' => 1
I really need the "&" in my var. Is there a way to encode that character to make it works?
Also, I really don't know why, but sometimes I get a forbidden http error with some strings passed as var1. Apparently, they have nothing special, for exemple, "Décarie Square" makes that error. Other strings with spaces and "é" are working fine.
Apache's mod_rewrite automatically decodes urlencoded strings when it does regex matching. But it only does this once, so you should be if you urlencode your string twice. This will re-escape all of those `%' characters.
try
$link = 'http://www.mydomain.com/'.urlencode(urlencode($str)).'/1';
or stop relying on rewrite rules and use a framework that handles URL routing properly.
Oh, and there should also be htmlentities() somewhere in there.
Apache will automatically translate (decode) the path. You must use a different encoding or even double encoding. Base 64 will work.
your $str isn't setup with key=val pairs
Try $str = 'var1=substr1&var2=substr2';
Two options:
Urlencode the string before urlencoding the query.
Replace all non alphanumerical chars with a dash or underscore
As for the forbidden error are you using http auth basic or digest?
Update may mistake try using htmlentities or htmlspecialchars instead of urlencode
I think I'm missing something obvious here but it is driving me crazy and I can't figure it out. I'm developing a WordPress plugin and part of it needs to take the WordPress post title and send that to a RESTful web service to do something else. So of course I want to rawurlencode() the post title since who knows what text might be in there. However, for some reason the output I'm getting has extra escape characters and I have no idea where they are coming from (and it's causing problems with the web service I'm calling obviously).
My code is fairly straight forward:
$topic = get_the_title($post_id);
$curl_post_fields = 'name=' . rawurlencode( $topic );
Yet when I print the output of those two strings I get:
topic=a & b
name=a%20%26%23038%3B%20b
Whereas I would expect the URL encoded string to be
name=a%20%26%20b
I have no idea where that extra %23038%3B could be coming from. If I'm reading the encoding on that correctly it translates to #038; but I still don't know where it's coming from.
There seems to be a html encoding in between as well, instead of &, & is in the encoded string. Probably because & has to be escaped in html, and the get_title function escapes this using html_special_chars or something like that.
I had some problems with that when i used an older php version
I am having a problem passing a json string back to a php script to process.
I have a json string that's been created by using dojo.toJson() that contains a / and looks like this:
[{"id":"2","company":"My Company / Corporation","jobrole":"Consultant","jobtitle":"System Integration Engineer"}]
When I pass the string back to the php script it get's chopped at the / and creates a malformed json string, which then means I can't convert it into a php array.
What is the best way of escaping the / in this string? I was looking at regular expressions and doing a string.replace() however my regex isn't that strong, and I'm not sure if there are better ways of doing this?
Many thanks
You shouldn't need to do anything special to represent a / in JSON - a string can contain any character except a " or (when not used to start an escape sequence) \.
The problem is possibly therefore in:
the way you parse the JSON server side
the way your parse the HTTP data to get the JSON string
the way you encode the string before making the HTTP request
(I'd bet on it being the last of those options).
I would start by using a tool such as LiveHttpHeaders or Charles Proxy to see exactly what data is sent to the server.
(I'd also expand the question with the code you use to make the request, and the code you use to parse it at the other end).
\/. Take a look here. The documentation is really easy to read, concise and clear. But unescaped / should still be valid in JSON's string so maybe your bug is somewhere else?
Ok. Anyway.
When passing variables to PHP don't use JSON - it's good for passing variables other way.
Instead you better use http://api.dojotoolkit.org/jsdoc/1.3/dojo.objectToQuery method and on PHP side parse standard PHP $_GET variables.
EDIT: Ok, I'm 'lost in the woods' here also, but here's a tip - check if you don't have some mod_rewrite rules in action here. Kind of seems like that.
Also, if you can send me the URL which gave you 404 (you can cut out domain part, i'm interested in script filename and all afterwards) maybe I can give you more detailed answer.
To be clear, whether you choose to send JSON to PHP or use regular form values is a matter of preference. It /should/ work either way. It sounds like you aren't url-encoding the JSON at the client-side so the server-side is treating / as a path delimiter. In which case its borked before json_decode gets to it.
so, try encodeURIComponent( dojo.toJson(stuff) )
json_encode() used to escape forward slashes. like this:
prompt> json_encode(json_decode('"A/B"'));
string(6) ""A\/B""
JSON_UNESCAPED_SLASHES was added in PHP5.4 to suppress this behavior.