engin aydogan
's journal
JQuery with template engines which uses dollar sign $
Aug 5th
For one project, we’re using NVelocity template engine and it uses $ sign for variables in the templates. This obviously conflicts with JQuery. When you try to use a JQuery function such as `$(“#foo”).show()`, template engine thinks it is a variable to be swapped with a value. This could be solved via;
1) Using JQuery without the $ syntax.
2) Using template engines mechanisms to print an actual $ character in the output.
or
3) Do as I do, put a space right after the $ character and NVelocity will be fine with it. For instance `$ .(“#foo”).show();`
I figured this third trick a few months ago and it took me a few minutes to find it again this morning. There! I won’t forget it again.
Chrome UTF-8 bug
Jul 28th
I cannot believe what I’m seeing. UTF-8 implementations failed miserably.
There’s a character in Turkish alphabet, it is capital “i”, just like “I” but with a dot on top of it. Why am I describing it instead of just showing it ? Well, WordPress also seems to be unable to handle it. From now on, [ci] refers to this special character in this post.
Chrome bug
toLowerCase() of Chrome 5.0.375.99 is buggy. If a string contains [ci], the resulting string has artifacts. For instance assume you have the original string “[ci]ello”, which is 5 characters long. When you feed it to toLowerCase() the resulting string will be 6 characters long with a “garbage” data after the converted [ci]. The results is something like i\xxxello. There’s a garbage after “i” which you can see via charCodeAt().
Firefox is plagued too
Then I tried in-case-sensitive RegExp matching. Trying to match “[ci]ello” with “/iello/i” failed both on Chrome 5.0.375.99 and Firefox 3.6.8.
Internet Explorer 8 kicked ass or what ?
Even though I, very objectively, hate IE series too I should note that IE8′s toLowerCase and RegExp matching works perfectly. In your face, all Microsoft haters :)
What about toUpperCase() ?
On all browsers toUpperCase converts “i” to “I” and not to “[ci]” and they should, since the context (language) is not known and English is naturally assumed to be the one in use, converting “i” to “I” is perfectly acceptable. Though it doesn’t make it right. In Turkish toUpperCase(“i”) should return “[ci]“. Which makes Javascript look inadequate at handling internationalization.
ExternalInterface performance on different browsers
Apr 15th
ExternalInterface is the API provided by Flash to communicate with its hosting environment. For my case, it is the browsers hosting the Flash “movie”. I noticed different performance behavior on each browser. This is my attempt to measure performance penalty caused by each browser.
Here’s the software versions:
Flash plugin version: 10,0,32,18
Chrome 4.1.249
Firefox 3.6.3
IE 8.0
How did I measure
1. I call Been.FComm.send() function in Javascript and timestamp (Tjs1) it. This JS function calls the send() in the Flash.
2. In the Flash application I timestamp (Tf1) send() function call.
3. In the Flash application I also timestamp (Tf2) handleData() and call been_fcomm_handle JS function.
4. Then I timestamp (Tjs2) been_fcomm_handle() in Javascript.
Flash application is written in Flex. It sends a data over a TCP socket and reads the response back. As all functions, send() and handleData() functions in my application also has a debug() call — which includes a timestamp.
Here’s how I implemented measurement in Flash:
private function debug(str:String):void
{
var date:Date = new Date();
output.appendText(date.getHours() + ":" + date.getMinutes() + ":" + date.getSeconds() + "." + date.getMilliseconds() + ": " + str);
}
private function handleData(event:ProgressEvent):void
{
var data:String = m_socket.readUTF();
debug("handleData"+data+"\n");
ExternalInterface.call("been_fcomm_handle", data);
}
private function send (value:String):void
{
debug("sending "+value+"\n");
m_socket.writeUTF(value);
m_socket.flush();
}
So that I can measure how long Flash thinks it takes my server to give a response.
On the other hand, I also measure the timings in JS layer. Here’s the related code pieces — simplified to death to only contain relevant codes.
Here’s how I implemented measurement in Javascript:
Been.Debug = new function() {
this.info = function(m) {
log(date.toLocaleTimeString() + "." + date.getUTCMilliseconds() + ": " + m);
};
};
Been.FComm = new function() {
this.handle = function(msg) {
Been.Debug.info("Been.FComm.Handle: " + msg);
}
this.send = function(data) {
Been.Debug.info("Been.FComm.send: " + data);
Been.Utils.getFlashMovieObject("FlashComm").send(data);
}
/* rest of the implementation */
};
Results
Here are the results samples.
Chrome
Avarage Flash request/response: 8.3ms
Avarage JS request/response: 161ms
Flash JS communication (marshaling) overhead: 161 - 8.3 = 152.7ms
Flash output
---------------------------------------------------------------------------------------
20:34:20.731: handleData{"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:34:20.719: sending {asf}
20:34:19.519: handleData{"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:34:19.513: sending {asf}
20:34:9.713: handleData{"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:34:9.706: sending {asf}
Javascript output
---------------------------------------------------------------------------------------
20:34:20.990: Been.FComm.Handle: {"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:34:20.720: Been.FComm.send: {asf}
20:34:19.710: Been.FComm.Handle: {"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:34:19.512: Been.FComm.send: {asf}
20:34:09.718: Been.FComm.Handle: {"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:34:09.702: Been.FComm.send: {asf}
Firefox
Avarage Flash request/response: 76ms
Avarage JS request/response: 77.6ms
Flash JS communication (marshaling) overhead: 77.6 - 76 = 1.6ms
Flash output
---------------------------------------------------------------------------------------
20:35:55.385: handleData{"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:35:55.276: sending {asf}
20:35:54.582: handleData{"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:35:54.506: sending {asf}
20:35:53.687: handleData{"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:35:53.644: sending {asf}
Javascript output
---------------------------------------------------------------------------------------
20:35:55.414: Been.FComm.Handle: {"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:35:55.303: Been.FComm.send: {asf}
20:35:54.610: Been.FComm.Handle: {"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:35:54.533: Been.FComm.send: {asf}
20:35:53.715: Been.FComm.Handle: {"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:35:53.670: Been.FComm.send: {asf}
IE
Avarage Flash request/response: 5.3ms
Avarage JS request/response: 7.6ms
Flash JS communication (marshaling) overhead: 7.6 - 5.3 = 1.3ms
Flash output
---------------------------------------------------------------------------------------
20:36:51.166: handleData{"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:36:51.162: sending {asf}
20:36:48.211: handleData{"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:36:48.207: sending {asf}
20:36:47.467: handleData{"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:36:47.459: sending {asf}
Javascript output
---------------------------------------------------------------------------------------
20:36:51.166: Been.FComm.Handle: {"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:36:51.161: Been.FComm.send: {asf}
20:36:48.211: Been.FComm.Handle: {"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:36:48.206: Been.FComm.send: {asf}
20:36:47.469: Been.FComm.Handle: {"Status":"FAILED","Error":"Internal server error.","ErrorNo":500}
20:36:47.456: Been.FComm.send: {asf}
Summary
| Browser | Flash – JS communication overhead (ms) |
| Chrome | 152.7 |
| IE | 1.3 |
| FF | 1.6 |
It looks like Chrome suffers from the most significant overhead, while IE and FF could be considered on a par.
Cross-domain data-push methods compared
Mar 31st
I’ve been playing with cross-domain (XD) data-pushing techniques lately and now I’ll try to compare each available technique. These techniques allows server to push messages to the client. A brief summary of comparison is available in the table below, following the table you can find more detailed explanation for each technique.
| Technology | Reading Data | Writing Data (HTTP GET) | Writing Data (HTTP POST) | Advantages | Disadvantages | Conclusion | |||
| XHR | No | Yes | No | XHR is good at error handling |
|
FAILBecause: a cross browser method with XHR for XD communication does NOT exist. |
|||
| Script | Yes | Yes | No |
|
|
Works |
|||
| IFRAME + hack | Yes | Yes | No |
|
|
Works |
|||
| IFRAME + form | No | Yes | Yes | Can send large data |
|
FAILBecause: see Disadvantages |
|||
| IFRAME + form + hack | Yes | Yes | Yes |
|
“Start navigation” (aka click) sound of IE when you do form.submit() (NOTE: This really is a deal breaker, funny fun though) |
FAILBecause: see Disadvantages |
|||
| Flash | Yes | Yes | Yes |
|
Note that I’ve tried very very hard to find disadvantages of this method.
|
Works |
|||
| Yes: Able to send request and read the response. i.e. Being able to send a request to http://foo.com/write.php?data=bar, which writes data “bar”, and in return being able to read the response (such as “Write Successful” or “Write Fail” Yes: Able to send request but cannot read the response No: Cannot send request nor response. |
|||||||||
Introduction
I’ve studied cross domain communication as it is two separate tasks; one is reading other one is writing.
Available Methods
1. XHR
XHR is the way to go with same-origin requests (i.e. non-XD), unfortunately it does not with with XD requests. So far browsers would simply throw an exception when you tried to do a XD request via XHR, which is defined by the standard.
If the origin of url is not same origin with the
XMLHttpRequestorigin the user agent should raise aSECURITY_ERRexception and terminate these steps.
A new standard is worked out called access-control which now enables you to do XD XHR requests. Essentially it is what Flash’s policy file is to the XHR. XHR is only allowed when the target domain explicitly allows your domain.
- Should not allow loading and exposing of resources from 3rd party servers without explicit consent of these servers as such resources can contain sensitive information.
You can find more detailed information about the reasons of these decisions in my previous post.
So what this means is;
- Only if a very new browser with the new specs implement is being used,
- and target domain explicitly allows the originating domain then XHR can be used for XD communication.
- and if target domain does NOT explicitly allows the originating domain, only simple requests such as GET will be send to the target domain, and response will not be readable by the script.
- If a browser with new specs implement is NOT being used, then a security exception will be thrown right away.
Conclusion: FAIL.
Because a cross browser method with XHR for XD communication does NOT exist.
2. Script
Script is one of the elements which are not restricted by the same-origin policy (SOP). Script is abused in such a manner that it allows us to do XD communication. Below figure demonstrates how script method works.
Here’s what’s going on in the above figure:
- origin.com tries to load a JS script from remote.com/service.php
- as the script from remote.com loads, it immediately calls a message handler in origin.com
- hence remote.com passed information to origin.com which is an actual XD communication.
Here’s what the mysterious $.getScript does roughly;
- Create a <script> element in the origin.com
- Set src (source) property to “http://remote.com/service.php”.
- Adds the newly created script element to <head> element of the page.
Of course, in practice JQuery does a little bit more to ensure performance and browser compatibility.
Conclusion: Works but…
- Data writing is handled with query parameters in the URL of the HTTP GET request. Such as http://remote.com/service.php?data=value. This comes with the restriction of the URL length. In practice, a 2kb of URL is said to be cross-browser compatible. So data writing is limited to 2kb.
- Long-polling is required to get a persistent connection going. i.e. once the server gives the response, you need to re-establish the connection. This wastes resources such as bandwidth.
- Error detection is not built-in. Browser does not tell if you if the server broke the ongoing TCP connection (which is the HTTP GET request). So you need to handle errors in your code.
- remote.com should be trusted, as it will execute code on your page.
3. IFRAME hack
This is a hack which is explained quite well in Facebook wiki.
Different from script method, this hack requires a proxy program (xd_receiver.php in the figure above). This has the advantage of you can filter the data coming from remote.com (facebook.com in the figure). But this is also has the disadvantage of adding another layer of maintenance in the chain.
Conclusion: Works but…
- All the problems with the script methods applies to this method, except the lust one, the remote.com trust issue.
4. IFRAME + form
This technique enables you to post data to remote.com, without apparent reload of the page (i.e. AJAX-ish).
Here’s how:
- You create a <form> element, set it’s .method to “POST” and .action to “http://remote.com/service.php”
- Create an <iframe> and insert the <form> element you’ve just craeted
- Call form.submit();
From my tests with Chrome and Firefox I’ve seen that this actually posts the data (I can see it on my server) but cannot read the returned result from the server. Which means you cannot see if the result of POSTing actually did something on the server. You just POST it.
Another deal breaker is the “click” sound Internet Explorer makes each time you call submit(). This practically renders this method useless itself.
Conclusion: FAILS because…
- You cannot read the response from the server from Javascript.
- Each time you call submit() method, Internet Explorer makes the click noise (which is called “Start Navigation”)
5. IFRAME + form + hack
I haven’t tested this technique in theory you should be able to merge the technique 3 and 4 together to form this. To make this happen, http://remote.com/service.php should make a HTTP redirect to http://origin.com/xc_receiver.php?data=response.
Though the “click” sound of Internet Explorer practically renders this solution useless too.
Conclusion: FAILS because…
- Each time you call submit() method, Internet Explorer makes the click noise (which is called “Start Navigation”)
6. Flash
This method has so much advantages that I’m very surprised that it is so rarely used. i.e. it is not used for Facebook chat.
In this method you use an invisible Flash object which provides an interface to the Javascript code via ExternalInterface.addCallback, and access to Javascript code via ExternalInterface.call(). It works like a charm and TCP connection capabilities of the Flash is naturally much much more robust than the above hacks. Flash also provides very good error handling.
Plus you can use binary protocols with this, which can reduce bandwidth from 10x to x easily. You can upload any amount of data and receive any amount of data. You can a real TCP connection ready for your command for all times. Spectacular!
As an example a sample Facebook chat packet is 686 bytes including HTTP headers but the actual data is only 179 bytes. Facebook uses long polling, so every packet must be wrapped in a HTTP packet, hence the overhead is quite significant. Also this data is packed in rather verbose JSON format. If it was also a binary format the savings would be more, such as 80 bytes instead of 686 bytes. Rationally speaking though, packing data in binary for WEB might not be very wise and might not just worth the effort. Just getting rid of off HTTP overhead saves %73 bandwidth. On the other hand a hypothetical binary protocol could have save 88%. While that little %15 bandwidth could mean a lot for high scale web sites, it might well not worth the effort since it complicates things and adds other layers to design. Anyways…
Flash is so good that it is hard to find an argument against it. I’ve tried really hard;
Flash is a plug-in!
Availability of Flash can be questioned. According to http://www.adobe.com/products/player_census/flashplayer/version_penetration.html, market penetration of Flash 9 is 99%. I think, this makes Flash a even more portable way than above solutions. And according to google-analytics of our site which receives 30k visits (I know not very big), 100% of the users have Flash.
Not available in mobile platforms!
True. Currently Flash support on mobile devices are limited. Though there’s this fact that, each mobile device inevitably requires its very own UI design. For instance, Facebook’s mobile HTML page dose not offer Chat functionality at all. Though other native applications for iPhone and Windows Mobile offers this service.
That’s to say, each mobile device will inevitably has its own UI anyway (which doesn’t use Flash). So this argument is not very sound neither.
Flash’s TCP connection could be blocked!
Common firewall set ups do not block outgoing TCP connections. And if you use a known port for your remote.com such as 80 or 443, your Firewall most likely can’t tell the difference. To tell the difference a statefull Firewall is required, and if a network has those firewalls most likely most of the sites (such as Facebook) are blocked anyway.
Another network problem could be that, all TCP connections are blocked and only HTTP Proxy is allowed, so that your browser is configured to use that HTTP Proxy by default. In this case Flash will fail. Though other methods mentioned above could also fail when a proxy is present. i.e. a long persistent connection which long polls use are not what HTTP Proxies are designed for.
Conclusion: Works
Finally
As you might have already noticed my personal bias is towards Flash, though I’m not sure why it isn’t wildly deployed as I’d imagine. I have successfully implemented the <script> and Flash methods myself, and I believe Flash is superior. I think only time can tell which is the best solution :)
Cheers.
Show off time! ENDA PLC controlling 2-axis servo motors via iPhone
Feb 25th
This is the project I’ve mentioned in my previous post.
In this project our goal was to control a mini golf club via iPhone accelerometers, in a wireless Wii-like manner, to demonstrate the connectivity capabilities of our device.
What we did is, iPhone continuously sending its absolute direction to our ENDA PLC (programmable logic controller), and guest software (ladder program) running on top of the firmware does some filtering and drives the servo motors.
YouTube video – while we were testing the system for the first time.
The guy controlling the golf club at first is my colleague who is the director of the whole PLC division, and he is the developer of the graphical ladder logic editor software which is available for free with our PLC devices. I’m the one responsible for the firmware of the device and some other stuff, and I’m the one scoring at 2:22 :)
So, this is basically a little visually programmable computer. You get the device, plot your logic in the graphical editor, it generates rather optimized C code, which is then compiled and downloaded to the PLC. Then the firmware runs this guest application.
Firmware’s goal is to provide a solid real time OS with robust IO. I’ve tried to engineer a completely asynchronous IO infrastructure, the result is well received by industry veterans as the device is able to handle simultaneous communication over all the communication ports (UART0, UART1, SPI0, SPI1, I2C, Eth) with no apparent overhead to the guest application. At some point, I could open-source the firmware — only after I clean up the ugly parts though :)
I’m also working on a relaying server project which offers zero-configuration connectivity to our devices. If the network it is attached to is connected to internet, you’ll be able to connect to the device without any configuration at all and no matter where the device is located in the world. Only things you need to know is the serial (MAC) and password of the device. I’m making initial tests of this system at the moment. I might write about it later.
Cheers :)
Cross-domain XHR, Access-Control, preflight
Jan 25th
It looks like my previous post about the browsers sending OPTIONS request instead of GET has nothing to do with Dojo, which got quite obvious as I saw Prototype is also behaving the same way. I’ve researched about the topic and here’s my insights.
It turned out that some new specifications were implemented in IE8, Safari 4, FF 3.5 and Chrome which allows you to do cross-domain XHR. Which means the pure JS implementation I have demonstrated wasn’t supposed to work at all unless this new specification was implemented. Here’s what the old XHR spec has to say about cross-domain (cross-origin) requests. Taken from http://www.w3.org/TR/XMLHttpRequest/#the-open-method
If the origin of url is not same origin with the
XMLHttpRequestorigin the user agent should raise aSECURITY_ERRexception and terminate these steps.
Not allowing cross-domain XHR was and is really a deal breaker and actually it pretty much stops you from implementing SOA (service oriented architectures) flexibly. But for some good reasons.
Here are a few theoretical scenarios:
- Imagine you are visiting attacker.com which serves a script that requests bank.com/?action=money_transfer&to=attacker&amount=999999. Assuming you have an active session with the bank, if your browser sends this request to bank.com along with the session cookie, attacker would be able to transfer money to himself. This is called CSRF (Cross-site request forgery)
- Imagine you are visiting attacker.com which serves a script that requests 10.0.0.50/confidential_intranet_document.html and sends it to himself via script. This means any client in the trusted LAN network might leak information from the LAN to internet.
- Imagine you are visiting trusted.com which happens to have a security hole so that the attacker can inject malicious code in its web pages. For instance, imagine you could embed Javascript in the messages in Facebook. When other users see that message and the Javascript code you injected works on their browser, you could read their cookies, hence steal Facebook session. This is called XSS (cross-site scripting).
Though there are other transport mechanisms, such as <script> element which is not restricted by this Same Origin Policy. These mechanisms were used instead of the obvious XHR method to achieve cross-domain requests so far. Though these elements are restricted in their own ways, see below for more detail.
There is a new specification being drafted to address these issues, http://www.w3.org/TR/access-control/ which is the reason why OPTIONS request was being sent instead of GET in my previous post. The new spec says that it is OK to send a simple request (which is defined as GET, HEAD and POST) cross-domain as long as there’s no custom header in it. If these conditions are not met, there should be a preflight request to ensure that the domain we’re requesting the document from allows us to fetch it — much like Flash’s policy file.
Note the custom headers clause above. That’s the exact reason why Prototype and Dojo was causing an OPTIONS request instead of GET, where regular JS was simply sending GET request. Dojo and Prototype adds custom headers to the requests.
So you might ask; cross-domain XHR was not allowed for a good reason, why is it being allowed now ?
Yes, cross-domain XHR is allowed now, but apparently no different than cross-domain requests you can send via img or script elements. Remember that you could always do cross-domain requests with img element too, but img element has two features that makes it not a security problem:
- img only can send the cookies for the domain it is loaded from. i.e. it is hard to use a remote session since it won’t send the target site’s cookie.
Consider the first scenario above. If the request does not include a cookie for the bank.com, there’ll be no session. It will be a anonymous request. (Of course unless the target site uses session ID as a part of the URL, and the attacker got that SID, which is very unlikely. And if he has the SID he’ll hijack your session all together anyway). - You cannot read the contents of an img element, hence you cannot steal sensitive information which you aren’t supposed to read.
Now, I have demonstrated myself in my previous post that cross-domain XHR worked out fine. My server received the GET request. BUT in the client xhr.responseText was empty and xhr.status was 0 (not 200). It is true that the request was actually made, but you cannot read the contents of the resource. Here’s what access-control spec says about this in http://www.w3.org/TR/access-control/#requirements
- Should not allow loading and exposing of resources from 3rd party servers without explicit consent of these servers as such resources can contain sensitive information.
One of the requirements of the spec is not to expose resources without explicit consent. From what I understand, here, explicit consent means Access-Control-Allow-Origin header. If the third party server allows other hosts to read its resources via this header, everything will be fine. So, this means that the new XHR is no security hole bigger than the IMG itself.
In fact, I’ve tested this. It turns out that when you add this header to your resource, cross-domain XHR starts to work to the fullest. i.e. you can read the content of the requested resource, as in, it is readable in xhr.responseText.
For your information, you can add any headers to your resources with mod_header module of Apache httpd. Just add this directive for whatever directory you want;
Header set Access-Control-Allow-Origin "*"
Keep in mind that, this will expose all of your resources in that directory for anyone to read. So, do this if your resources are public anyway. Or just allow the hosts you want. It could be better to do this in the programming layer, such as PHP or ASP.NET.
So in conclusion, with the new access-control spec, XHR is pretty similar to the Flash’s security design. Browser checks if the third party host allows you to read your resources, if so your script is allowed to read it. Note that you can make the request anyway, but reading the resource is not allowed.
This is a nice step forward actually, but since it will take some time that majority of the market is using browsers implement this new spec, web developers are bound to use iframe or script transports for cross-domain request.
First Dojo impressions
Jan 22nd
I started implementing a daemon in Java. Essentially all our devices will connect to it and wait for commands over TCP/IP. Additionally it will offer a web service REST API over HTTP, so that administrators can send/receive data from the devices. This is basically a relaying architecture between devices and administrators. It overcomes any network topology problem (i.e. NAT traversals.) with performance penalty and bandwidth costs of relaying. Web service API is going to be totally self-sufficient, such that totally static HTML pages with Javascript can interact with it.
I’ve implemented the skeleton of the daemon, devices connect to it and it also offers web service API. I tested the web service API by simply requesting the web service URL from the browser as I would do any other URL and confirmed that the correct (JSON) response is given. It was time to see how it is to build a web UI for it. Given its reputation and apparent support, I chose Dojo to implement the web UI with totally static HTML pages. Here’s my experience.
Documentation
From the main Dojo site, it was stated that latest stable release was 1.4.0, and it was the default download link. So I grabbed it. By looking at an example in the demo section, I get an Ajax query working in seconds, only to find out that it is not working for me. Instead of a GET request it was sending OPTIONS request, more on this later. Obviously, I wanted to look at the documentation. Clicking on the Documentation link on the main Dojo site takes you to a place where documentation for 1.4.0 is not offered.
Luckily there were a handful of helpful folks in #dojo @ irc.freenode.net, whom told me that new documentation UI is on its way.
The first one was inaccurate by the time I’m writing this Dojo.xhrGet property list was quite short. I found doc-staging to be more accurate and since it is documentation rather than just reference it also offered much more detail.
Dojo.xhrGet results in OPTIONS request instead of GET
The firs thing I’ve tried with Dojo was obviously the Ajax API.
function getText() {
dojo.xhrGet({
url: "http://localhost:8182/hello",
load: function(responseObject, ioArgs){
return responseObject;
},
error: function(response, ioArgs){
dojo.byId("toBeReplaced").innerHTML =
"An error occurred, with response: " + response;
return response;
},
handleAs: "json"
});
}
This code snippet is taken from Dojo examples which can be found in the official web site. I removed the content of the first function though, it was supposed to do DOM manipulation obviously.
When I run this code, I noticed OPTIONS request in my daemon’s logs. When I was requesting the same URL by writing it to the address bar of the browser all I see was GET requests in my logs, as expected.
Then I’ve tried a pure JS implementation.
var client = new XMLHttpRequest();
client.onreadystatechange = handler;
client.open("GET", "http://192.168.1.94:8182/hello");
client.send();
With this simple implementation I started seeing GET requests in my server as expected. So Dojo should be doing something in a different way. I walked through the Dojo code, thanks to Firebug. But it turned out that the code is indeed very similar to the regular JS code and there were no obvious bugs, as I expected. Then, I examined the HTTP requests via invaluable Wireshark.
Here’s what I got for Dojo request.
OPTIONS /hello HTTP/1.1 Host: 192.168.1.94:8182 Connection: keep-alive User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.49 Safari/532.5 Cache-Control: max-age=0 Access-Control-Request-Method: POST Origin: file:// Access-Control-Request-Headers: X-Prototype-Version, X-Requested-With, Content-type, Accept Accept: */* Accept-Encoding: gzip,deflate Accept-Language: tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-9,utf-8;q=0.7,*;q=0.3
And here’s what a regular JS XHR looks like.
GET /hello HTTP/1.1 Host: 192.168.1.94:8182 Connection: keep-alive User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.49 Safari/532.5 Cache-Control: max-age=0 Origin: file:// Accept: */* Accept-Encoding: gzip,deflate Accept-Language: tr-TR,tr;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-9,utf-8;q=0.7,*;q=0.3
Obviously the difference is Access-Control-* properties. I tracked down the source of this was the lines from 10474 to 10477 of dojo.js
// FIXME: is this appropriate for all content types?
10474 xhr.setRequestHeader("Content-Type", args.contentType || _defaultContentType);
10475 if(!args.headers || !("X-Requested-With" in args.headers)){
10476 xhr.setRequestHeader("X-Requested-With", "XMLHttpRequest");
10477 }
Funny thing, there’s a FIXME there :) Anyway, when I commented out these lines the request headers were the same for both pure JS Ajax implementation and the Dojo Ajax implementation. And both are now sending GET requests as expected.
I consulted the folks at #dojo about this problem and at first they couldn’t create the problem. Than I’ve stated that the web UI is hosted at X and the web service API of the deamon was at X:P. So it is a cross-domain request. To be precise the script was hosted at http://192.168.1.94/test.html and web service API of the daemon was available at http://192.168.1.94:8182/hello. sfoster from #dojo generously spent some time to test this situation and he also confirmed that OPTIONS requests were being sent. Apparently when Access-Control-* headers are set and it is a cross-domain request browsers decide to send OPTIONS request instead of GET. This is tested with Chrome and Firefox.
Though I believe Access-Control-* properties are there for a good reason. This same problem could also be demonstrated on prototype javascript framework, apparently they are taking the same approach on this.
I’m not sure what is the best practice on this yet, I’ll try to consult some core Dojo developers about this and figure it out.
Application deployment in jailbreak iPhone 3.1.2 with Xcode 3.2.1
Jan 5th
I recently got a Macbook to develop an application for our company to show off at the industrial automation fair this year. I’ll probably post about the project later, if I can manage to build it.
Since I have no intention to put any application on App Store, and I don’t want to wait for the approval process, I decided to deploy my application on a jailbroke iPhone. Here’s how:
- Visit blackra1n.com and jailbreak your iPhone.
- Follow these instructions carefully. (backup)
- Above instructions does not mention that you have to select the certificate you have just created explicitly in Xcode. You can do it by selecting your project in “Groups & Files” pane, then hitting Command + I. This will pop up Get Info window for the project. In the Build tab, Code Signing category select the certificate you have just created.
- Now you can get the infamous “No provisioned iPhone OS device is connected.” error as I did. With the inspiration from this article (backup), in Xcode I did Window -> Organizer and selected my iPhone and clicked Use for development.
- Now I’m able to deploy my apps to the jailbroke iPhone.
Final words… I must say, in contrast to this, programming a Windows Mobile device is as easy as plugging the device to your computer and clicking debug button.
Even though Apple’s intention to strictly supervise the applications going into App Store is a good choice (because you don’t have crap-ware that cripples your device as you’d see in Windows platforms), restricting one from programming his own device is plain stupid.
NOTE: Above method is a pain in the ass and it does not support build-and-go/debug feature of Xcode — though there are documentation that explains how to do it. I end-up buying a subscription for $99, the whole process took 16h, and I had to fax a signed document to Apple. So if you are in a region that you can do subscription online, you’d be done in much shorter time.
Conclusion: Buy a subscription :)
Fikifiki – Very simple sudoku solver in C
Dec 24th
It was like 4 months ago. I was waiting for something indefinitely in a hospital. Luckily though I had my old cute iBook with me, which includes a gcc in it! Even Eclipse! Then I saw the sudoku puzzle in the papers. So I quickly coded a sudoku solver in C in a couple of hours. I could have had added many algorithms in it, but I just added the most simplest one and it surprisingly worked in my first try :) This one simple algorithm is able to solve easy leveled sudoku puzzles. Though one can add as many algorithms as necessary. Everything is 655 lines of C code — with all the formatting and the comments (if any). Here’s the code. This will probably be used by some lazy ass students :)
You can compile by either invoking “make” in Release or Debug directories, or just import the project in Eclipse and enjoy there.