Go Back   SmartClient Forums > Technical Q&A
Wiki Register Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Search this Thread
  #11  
Old 30th May 2008, 11:51
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,342
Default

Hi Schlonz,

Because of the substantial dependent libraries, hosting with Google code and simply linking from here probably makes the most sense.

We'll try to get you a patch for the problem with 500 server errors so you don't have to keep working with the dataFormat:"custom" pathway. However, it looks like it would be pretty straightforward to create such a patch yourself, for example, override _handleJSONTextReply and call the original function only after ensuring that the jsonText argument is an empty String rather than null.
Reply With Quote
  #12  
Old 31st May 2008, 11:52
schlonz schlonz is offline
Registered Developer
 
Join Date: May 2008
Posts: 10
Default

Please see http://forums.smartclient.com/showthread.php?t=2051 -
Announcement: CustJsonRPCDataSource - a JsonRPC data source. :)
Reply With Quote
  #13  
Old 6th Jun 2008, 10:50
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,342
Default

We've fixed the problem with HTTP 500 server responses on JSON data types. The fix will be included in the upcoming 6.5.1 maintenance release.

Regards,
Isomorphic Software
Reply With Quote
  #14  
Old 19th Jul 2008, 13:43
schlonz schlonz is offline
Registered Developer
 
Join Date: May 2008
Posts: 10
Default

Quote:
Originally Posted by Isomorphic
We've fixed the problem with HTTP 500 server responses on JSON data types. The fix will be included in the upcoming 6.5.1 maintenance release.
Hi Isomorphic,

Are you sure the problem has been solved?

I still run into the same problem when HTTP server responses are e.g. 500 or 404.

I might be completely wrong since I am not so familiar with the smartclient code, but:

You changed DataSource.js but simply introduced a check in _handleJSONTextReply:

Code:
if (rpcResponse.status >= 0) {
an in there you run

Code:
if (evalText.match(/^\s*\{/)) {
which fails as described above. I believe the reason for this behaviour is caused in RPCManager.js in performTransactionReply. At the end it does the following:

Code:
            // All HTTP 2xx codes indicate success.  Success codes other than 200 OK are
            // somewhat obscure, but are used by Amazon S3 and possibly other REST APIs
            if (status > 299 || status < 200) { //error
                var url = transaction.URL;
                if (transaction.isProxied) {
                    url = transaction.proxiedURL+" (via proxy: " + url +")";
                }
                results = this._makeErrorResults(transaction, {
                    data : "Transport error - HTTP code: "+ status
                           +" for URL: " + url
                           + (status == 302 ? " This error is likely the result"
                              + " of a redirect to a server other than the origin"
                              + " server or a redirect loop." : ""),
                    status: isc.RPCResponse.STATUS_TRANSPORT_ERROR
                });
                this.logDebug("RPC request to: " + url 
                             + " returned with http response code: " 
                             + status +". Response text:\n"
                             + xmlHttpRequest.responseText);
                             
            }
That means, rpcResponse.status will be 0 and therefore _handleJSONTextReply will perform the evalText.match check. But RPCManager.js/performTransactionReply has set jsonText to an Array:

Code:
[{data: "Transport error - HTTP code: 404 for URL: /rpc/custJsonRPCDataSource_jsonrpc"
status: -90}]
And of course the Array does not do well with .match.


I was about to check whether CustJsonRPCDataSource (http://forums.smartclient.com/showth...light=json-rpc) has to be changed for smartclient 6.5.1. It seems to work fine as long as you use dataFormat: "custom" for backends which answer with HTTP status codes > 299 for Json-RPC errors.

If you have a look at CustJsonRPCDataSource.js/_handleJSONTextReply - it handles such situations by taking into account that the returned result can be a string, array or whatever else.


Regards,
Erich
Reply With Quote
  #15  
Old 20th Jul 2008, 13:59
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,342
Default

Hi Erich,

This check:
Code:
if (rpcResponse.status >= 0) {
should be safe. At that point, only a negative status should indicate an error. From your description, you seem to say that you have a status of 0, but indicating an error condition like 500 or 404. Is that the case?

If so, are you accesing your server functions through a filesystem URL like "file://", or some other non-HTTP means?
Reply With Quote
  #16  
Old 21st Jul 2008, 12:45
schlonz schlonz is offline
Registered Developer
 
Join Date: May 2008
Posts: 10
Default

Hi Isomorphic,

Just try the following served from your http server:

Code:
isc.DataSource.create({
    ID: "countryDS",
    dataFormat: "json",
    fields:[
        {name:"countryCode", title:"Code"},
        {name:"countryName", title:"Country"},
        {name:"capital", title:"Capital"}
    ],
    operationBindings : [
        { operationType:"fetch", dataURL:"/this_path_does_not_exist/leading_to_a_404"}
    ]
})

isc.ListGrid.create({
    ID: "countryList",
    width:500, height:224, alternateRecordStyles:true, showAllRecords:true,
    dataSource: countryDS,
    autoFetchData: true
})
It tries to access a non-existing URL and will get a http status 404 from your http server. Result: GUI 'hangs', user can only escape by pressing the refresh button. rpcResponse.status = 0, evalText.match problem.

BTW: It does not matter whether you use DataSource, RestDataSource or my CustJsonRPCDataSource.

If your smartclient GUI is a bit more complex it totally ruins your GUI since the user has to hit refresh.

Of course the example above show a bug in the code (pointing to a non-existing URL) which can be soved upfront. But I guess there are real world situations which do not constitute a bug since they cannot be forseen (proxy errors, etc.).

Furthermore the Json-RPC over http 2.0 proposal demands to send back Json-RPC errors as http status codes e.g. 404, 500, etc.

I think it would be very good if one could catch this error and present an error message or handle the answer in whatever way you want.
Or in the case when you want to support the json-rpc over http 2.0 proposal (or similar APIs) it will be necessary to handle e.g. 404 just the way as status 200 since you might want to examine the body further. E.g. this could be the server's answer for a Json-RPC 2.0 'method not found' error:

Code:
HTTP/1.1 404 Object Not Found
Server: bluepeter/0.1
Date: Mon, 21 Jul 2008 20:32:08 GMT
Content-Type: application/json-rpc
Content-Length: 80

{"jsonrpc":"2.0","error":{"code":"-32601","message":"Method not found."},"id":1}
The comment in the code from RPCManager.js quoted in my previous message
Quote:
Success codes other than 200 OK are somewhat obscure, but are used by Amazon S3 and possibly other REST APIs
suggests that supporting results other than status 200 was also the intention.

Of course http status <> 200 can be handled by using dataFormat: "custom" (see CustJsonRPCDataSource) but this leads to pretty ugly near-copies of what you already implemented in DataSource.js.

Regards,
Erich
Reply With Quote
  #17  
Old 23rd Jul 2008, 12:50
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,342
Default

Hi Erich,

Hhmm, interesting. This problem now only happens with the LGPL version of SmartClient 6.5.1. We're looking into why this should be, but what I said about filesystem URL's seems to be a part of it - if you change the URL in your example from:
Code:
 
"/this_path_does_not_exist/leading_to_a_404"
to:
Code:
 
"http://this_path_does_not_exist/leading_to_a_404"
it starts to behave as I would expect (ie, rpcResponse.status is negative, and so the fix made for 6.5.1 works). As I say, we're looking into why the original example behaves differently.

Incidentally, the intention *is* that HTTP responses other than 200 are catchable, and you should be able to catch errors of this sort and deal with them however you like, via transformResponse(). Obviously, that isn't going to work whilst this issue is still in place, but that's the intention!

Regards,
Isomorphic Support
Reply With Quote
  #18  
Old 7th Aug 2008, 03:32
Isomorphic Isomorphic is offline
Administrator
 
Join Date: May 2006
Posts: 38,342
Default

We have now solved this problem in the LGPL version. As this has been quite a long-standing issue, we have released the fix as a patch so you don't have to wait for the next maintenance release. The patch code is available in the Addendums forum.

Regards,
Isomorphic Software Support

Last edited by Isomorphic; 7th Aug 2008 at 11:59..
Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search


© 2010,2011 Isomorphic Software. All Rights Reserved