Can someone explain the following result.
Request:
?q=argentini%C3%AB
Code on requested page:
<Cfoutput>cgi.query_string: #cgi.query_string#</Cfoutput>
<Cfoutput>url.q: #url.q#</Cfoutput>
Output on requested page:
cgi.query_string: argentinië
url.q: argentini?
For some reason url.q outputs to argentini? and not argentinië. I think this has something todo with the encoding of the different variables.
Update:
After further testing i figured out that the problem is in the Helicon ISAPI_Rewrite plugin for IIS, not coldfusion.
Related
I got a request from a customer that he wants to be able to type the query string of my web service with parameters in the IE10 address bar and get the service results. The parameters include string in Hebrew, like:
http://mywebsite.com/service.asmx/foo?param1=123¶m2=מחרוזתבעברית
It seems to me that that IE10 won't encode the query string parameters - every non-ASCII character that goes after the ? mark would be turned to '3f' byte, though it does encode what goes before the ? mark - the url itself.
For example, if i try to reach the url (the parameter is fictional, url is not, and I have no connection with the site)
http://www.shlomo.co.il/pageshe/sales/רכב-למכירה.asp?param=פאראם
and look in wireshark for the bytes I send to the server, it shows me
You can see it does substitute the hebrew part of the URL with urlencoded string, but substitutes the hebrew parameters with ?????, which are '3f's.
The same string in chrome would be encoded in it's entirety:
GET http://www.shlomo.co.il/pageshe/sales/%D7%A8%D7%9B%D7%91-%D7%9C%D7%9E%D7%9B%D7%99%D7%A8%D7%94.asp?param=%D7%A4%D7%90%D7%A8%D7%90%D7%9D HTTP/1.1
I tried it on machines with win7/IE10 and winXPheb/IE8.
My IE settings are (especially checked the "Always show encoded addresses option" to see if it helps and restarted, but made no difference):
I tried to search around for any info about the issue, but didn't find much of it.
My questions are:
Is it indeed like this, or am I missing something?
Is this behavior documented anywhere?
Are there any settings in IE/Win which enable the parameters encoding.
p.s. Sure if I was developing the client/web ui, I would simply urlencode my query, but my request from customer was exactly to paste the query to IE address bar, that's why I'm interested in this specific behavior.
Thanks.
Yes, your observation of the behavior is accurate. Internet Explorer 10 and below follow a complicated algorithm for encoding the URL. This was allegedly updated in Internet Explorer 11, but I've found that the new option doesn't seem to work.
The "Always show encoded addresses option" concerns whether PunyCode is shown for IDN hostnames, and does not impact the query string. Send UTF-8 URLs mostly applies to the encoding of the path, although it can also affect other codepaths
The behavior isn't fully documented anywhere. I'd meant to write a full post on my IEInternals blog about it but ended up moving on from Microsoft before doing so. There's a partial explanation in this blog post.
Yes, there are settings that impact the behavior. The Send UTF-8 URLs checkbox inside Tools > Internet Options > Advanced is one of the variables that determines how URLs are sent, but the option does not blindly do what it implies (it only UTF-8 encodes the path, not the query string). Other variables involved include:
Where the URL was typed (e.g. address bar vs. Start > Run, etc)
What the system's ANSI codepage is (e.g. what locale the OS uses as default)
The charset of the currently loaded page in the browser
As a consequence of these variables, you cannot reliably use URLs which are not properly encoded (e.g. %-escaped UTF8) in Internet Explorer.
Unfortunately this is still true for Internet Explorer 11 (build 11.0.9600.17358, win7-x64)
I saw that you can not unfortunately change the web server. However those who are developing new services may consider changing request parameters into path variables, e.g. from http://myserver.com/page?τεστ into http://myserver.com/τεστ/
If the client is calling the web-service from javascript,
encodeuricomponent can be used. In your case encodeuricomponent("מחרוזתבעברית");
http://www.w3schools.com/jsref/jsref_encodeURIComponent.asp
I'm panicking a little, so sorry if I haven't explained well enough.
I've dealt with quite the nightmare of a permalink restructuring experience
Old permalink= sitename/archives/postid
desired new= sitename/postname
tried everything it seems. I've even dabbled with /?p=$1 (<-----that nonsense!). But now i'm getting some crazy error when i go to my old permalink structure that reads:
Oops! Google Chrome could not connect to 0.0.37.89
Suggestions:
Try reloading: 0.0.37.89
and this was supposed to be "redirected".
I give up. please help.
sitename= brightontheday.com
I used the redirection plugin to redirect all old URL permalinks (/archives/postID) to the new permalink (/postID/postname)
also, the issue appeared to be due to cashing via cloudfare. It's important to to note that one should put cloudfare in "developer mode" while making site wide changes.
Situation: I am trying to call the LinkedIn API from a ColdFusion CFC to get the user's profile and network (connections). The LinkedIn API states that to do this you must call a URL with scope=r_fullprofile+r_network.
Issue: ColdFusion is automatically encoding the URL, so the plus sign is getting encoded, and LinkedIn is rejecting my call. Is there any way around this? I've posted a link below to some code snippets on github which I believe illustrate the issue.
https://gist.github.com/4535364
Any help would be appreciated!
I have searched around on this for a bit and I am seeing lots of examples where ColdFusion is not playing nicely with the LinkedIn API. So I'm afraid if you do get passed this issue (although I have not come up with an alternative yet) another will crop up. While searching I found several suggestions from people to use the linkedin-j, A Java wrapper for LinkedIn APIs instead. Here are some of the references that I found:
Working example Coldfusion and Linkedin API
LinkedIn-J does not return educations
401 Unauthorized response. API people/~ and people/id=; ColdFusion, cfhttp
Problem updating status - 401 unauthorized - ColdFusion
linkedin-j Getting Started
Side Note Your github code example is making a cfhttp call to 'receiver.cfm' but you called the file 'cfhttp_receiver.cfm'. In this line:
<cfhttp url="http://#cgi.http_host#/sandbox/receiver.cfm?scope=#url.scope#" method="post" resolveurl="no">
The scope field is a space delimited list.
The + character is commonly used as a shortcut for space, since it's more readable than %20 (which is what space encodes to).
If using a plus character results in an encoded plus (%2B) being sent, then you are left with two other ways of putting the space into the URL:
using a literal space character, or
using an encoded space %20
Try both of those options, ideally using a network snifer (e.g. WireShark) so that you can see accurately what is being sent.
Update: As per comments below, %20 is correct, but the signature based string needs to be encoded again, so for that the % becomes %25, giving a result of %2520.
CFWheels has the URLFor() function for getting the internal URL based on supplied arguments. Is there a way to get the internal URL without supplying any arguments?
For example:
Given a user navigates to "http://somedomain.com" or "http://somedomain.com/about/" or "http://somedomain.com/contact/" is there a method like ReWrittenURL() that returns something like "/" or "/about/" or "/contact/"?
Using URLFor() with no arguments returns "/home/index" or "/about/index" or "/contact/index".
CGI.SCRIPT_NAME returns "/rewrite.cfm"
Obviously with Javascript using document.location.href I can get what I'm after.
Does CGI.path_info have the value you're looking for?
edit
At first, I deleted this post, being utterly confounded. Now I've done a little test - I downloaded the latest wheels core files (1.1.6), extracted to an IIS 7.5 (with URL Rewrite module installed) + CF9 webserver, and edited the "web.config" file in the core root, setting "enabled='true'" for the rewrite rule. Also, since I was running this example from a subfolder, I changed the path from "/rewrite.cfm" to just "rewrite.cfm". This got me to the point where I was able to successfully requests urls like this:
http://server/wheelstest/wheels/wheels
From here, I edited the layout.cfm under views/wheels, adding:
<cfdump var="#cgi#">
When I then request the above URL (/wheelstest/wheels/wheels), I see the dump for the cgi scope. Under path_info, this is the value: /wheels/wheels.
Next, I added a blank "index.cfm" file under views/wheels.
When I request /wheelstest/wheels, I get this for path_info: "/wheels".
When I request /wheelstest/wheels/, I get this for path_info: "/wheels/".
When I request /wheelstest/wheels/index, I get this for path_info: "/wheels/index".
When I request /wheelstest/wheels/index/, I get this for path_info: "/wheels/index/".
So basically - cgi.path_info is doing for me exactly what you describe you want. What is different about your setup than mine, such that it isn't returning that value for you?
there might be a better way to do this... but here I go anyway
every page gets sent the #params#
<cfdump var="#params#">
<cfoutput>#params.action#/#params.controller#/#params.key#</cfoutput>
<cfabort>
try putting that in a controller and see the results
the problem is that if the objects inside the params object don't exist you get an error. So the path that gets generated needs to check if the struct key exists and edit accordingly.
CGI.Path_Info will give you the desired results. I've been trying different options however they all failed and went into the redirect loop. As soon as I switched CGI.path_info it all started well.
There is an ASP application made to co-exist with other .net web apps. The cookies for the asp page is actually written to the client from an aspx page. So we have something like:
Response.Cookies("Credo")("ID") = "ido sans lum"
sent to the client.
The ASP page receives this cookie, but strangely gives corrupt results:
sID = Request.Cookies("Credo")("ID") ' this gives "idosanslum"
Unfortunately I don't understand why. I checked HTTP_COOKIE server variable in ASP, and even it said something like:
HTTP_COOKIE:...;Credo=ID=ido sans lum&DomainID=5&...;...
So I believe this means the cookie is being sent from the browser correctly, but Request.Cookies("Credo")("ID") is giving me wrong results.
Am I messed up with some configuration or is this a known bug.
There is a KB article on this problem at the Microsoft support site: http://support.microsoft.com/kb/262444
Hope this helps.
Update:
The proposed fix from the article is to encode your cookie content. In Classic ASP I think the following will work:
Response.Cookies("Credo")("ID") = Server.URLEncode("ido sans lum")
Please give it a go and let me know what you find.