[auscope-geosciml] RE : URI resolution and javascript sandbox

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Mon Aug 9 05:03:08 EDT 2010


So we need a resolver (which is the proxy application).

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Tellez-Arenas Agnes
Date: lun. 2010-08-09 03:14
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] URI resolution and javascript sandbox



Hi Eric

You can indeed use a proxy, but you don't need a specific "uri" proxy. You just need some web application that request any link you send to it and give you (give to the javascript) the response.
On 1G, Javascript request a simple page proxy.jsp?url=http://otherdomain/blabla/blabla

The only possibility to have cross-domain javascript is to use JSON (but I don't remember how!).

Agnès


-----Message d'origine-----
De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Boisvert, Eric
Envoyé : dimanche 8 août 2010 19:58
À : auscope-geosciml at lists.arcs.org.au
Objet : [auscope-geosciml] URI resolution and javascript sandbox


Sorry for the technical question here, I hope some programmers on the list (Ben ? Agnès ?) can tell me what they think.

I'm trying to implement a test case where a web client would read a GeoSciML file loaded with URI references.  I tried to implement something in javascript that could defer those reference and do something with them.  But I've been stopped by the fact that Javascript runs into a security sandbox that prevents it from dynamically reading from any other domain than the one the page comes from.  There are tricks to circumvert this problem

http://usejquery.com/posts/9/the-jquery-cross-domain-ajax-guide

the most straighforward is to implement a server proxy (all the solution are some sorts of proxies anyway).  Anyway, bottom line is that http URI in a web environment cannot be used as is (unless the web application happens to be at the same place, which is unlikely because we expect URI from various places) and therefore does not resolve (no pun intended) the resource deference problem (you need a proxy) at least in a WEB application, which is likely to be the most common one (1G portal comes to mind)

Now, I remember the great debates about URN and location of the resolver.  Doesn't sandbox restriction kind of impose where this resolver should be ?.  we need to configure a proxy anyway, which is not terribly different from configuring a resolver location ....

just a though.  Am I missing something ?

Eric





<http://usejquery.com/posts/9/the-jquery-cross-domain-ajax-guide> 


_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
**********************************************************************************************
Pensez a l'environnement avant d'imprimer ce message
Think Environment before printing

Le contenu de ce mel et de ses pieces jointes est destine a l'usage exclusif du (des) destinataire(s) designe
(s) comme tel(s).
En cas de reception par erreur, le signaler e son expediteur et ne pas en divulguer le contenu.
L'absence de virus a ete verifiee e l'emission, il convient neanmoins de s'assurer de l'absence de
contamination a sa reception.

The contents of this email and any attachments are confidential. They are intended for the named recipient
(s) only.
If you have received this email in error please notify the system manager or the sender immediately and do
not disclose the contents to anyone or make copies.
eSafe scanned this email for viruses, vandals and malicious content.
**********************************************************************************************

_______________________________________________
auscope-geosciml mailing list
auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 6282 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20100809/535c5381/attachment.bin>


More information about the GeoSciML mailing list