Dear Stanbol contributors, The point is to be able to use the Stanbol REST API even if technically there's no way to control the request header parameters. (This is the case when making a cross-site request from Internet Explorer 8 & 9)
So any of the discussed solutions that solve this are fine with me. This feature would bring the usefulness of Stanbol a step forward in combination with the VIE javascript library when used from Internet Explorer. I hope someone could implement it soon! Who? Szaby P.S. Some of you stated that this discussion should happen on the stanbol-dev list so I am moving this discussion now from the iks-wip list to the stanbol-dev list. For those of you who are not on the iks-wip mailing list here is the whole discussion again started on wednesday (the newest message is at the bottom, sorry for that): *VIE, Stanbol and Internet Explorer 8 & 9* 8 messages ------------------------------ *Szabolcs Grünwald <[email protected]>* *9 November 2011 18:02* To: iks-wip <[email protected]> Dear Stanbol and VIE developers, As you may guess it's a rocky way to get something run on Internet Explorer. Now I'm on this way of getting VIE and its Stanbol Service running on it and I came to a painful point where I see dark in terms of ever solving the problem of sending cross-domain requests (CORS is implemented in Stanbol) from Internet Explorer 8 and 9 without to change Stanbol's REST API. In Chrome and Firefox the XMLHttpRequest object of the browser takes care of the preflight requests (OPTIONS request before a cross-domain POST for example). In Explorer this is not that easy. There's another object for handling cross-domain requests, the XDomainRequest. This can be made to allow cross-domain requests depending on trust zones of local, intranet and internet. For handling the XDomainRequest we can use a special jQuery.ajaxTransport, but the problem is this: the XDomainRequest object has some limitations. [1] The most painful of these limitations is that it's not possible to set specific accept-headers on the requests, which is essential for using the Stanbol REST API. As Rupert and I tried to figure this out, we could only think about one workaround: Using GET parameters on the request URI for setting the access header. Any ideas and thoughts how to solve this issue? [1] http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx -- Szaby Grünwald MA Web developer Knowledge and Media Technologies Salzburg Research Forschungsgesellschaft m.b.H. Jakob Haringer Straße 5/3 5020 Salzburg, Austria Phone: +43 662 2288 301 Fax: +43 662 2288 222 ------------------------------ *Olivier Grisel <[email protected]>* *9 November 2011 18:14* To: Szabolcs Grünwald <[email protected]> Cc: iks-wip <[email protected]> I think we could indeed have dual content type negotiation handling. For instance by using the a "format" query parameter if there and falling back to the HTTP "Accept:" header if no "format" query parameter is provided. BTW if we decide to go this we should discuss this on the stanbol-dev mailing list. -- Olivier ------------------------------ *Stefane Fermigier <[email protected]>**9 November 2011 21:17* To: Olivier Grisel <[email protected]> Cc: Szabolcs Grünwald <[email protected]>, iks-wip < [email protected]> On Nov 9, 2011, at 6:14 PM, Olivier Grisel wrote: > I think we could indeed have dual content type negotiation handling. > For instance by using the a "format" query parameter if there and > falling back to the HTTP "Accept:" header if no "format" query > parameter is provided. Indeed. The CMIS browser binding specs authors seem to have had similar issues, it might be worth looking at how they did solve them: http://tools.oasis-open.org/version-control/svn/cmis/trunk/BrowserBinding/specification/cmis-spec-v0.5-browserbinding.doc > BTW if we decide to go this we should discuss this on the stanbol-dev > mailing list. Indeed. S. -- Stefane Fermigier http://twitter.com/sfermigier - http://www.linkedin.com/in/sfermigier "Although I suffer from the defeats, I learn to achieve more victories, and that's the essence of job satisfaction." - Gerald Weinberg "There's no such thing as can't. You always have a choice." - Ken Gor ------------------------------ *Reto Bachmann-Gmür <[email protected]>* *10 November 2011 00:03* To: Olivier Grisel <[email protected]> Cc: Szabolcs Grünwald <[email protected]>, iks-wip < [email protected]> I suggest to have optional query parameters starting with "header_" and followed by the name of the header for any request uri. For this I suggest adding a servlet filter that looks for such query parameters and forwards the http request to the chain with the request header set to the value of the query parameters. Such a module would not need to depend on any other Stanbol module, as such it could also be used with other system using the OSGi http service. Reto [Quoted text hidden] > [Quoted text hidden] > > -- > Olivier > _______________________________________________ > iks-wip mailing list > [email protected] > http://lists.interactive-knowledge.org/cgi-bin/mailman/listinfo/iks-wip > ------------------------------ *Reto Bachmann-Gmür <[email protected]>**10 November 2011 00:07* To: Olivier Grisel <[email protected]> Cc: Szabolcs Grünwald <[email protected]>, iks-wip < [email protected]> I suggest to have optional query parameters starting with "header_" and followed by the name of the header for any request uri. For this I suggest adding a servlet filter that looks for such query parameters and forwards the http request to the chain with the request header set to the value of the query parameters. Such a module would not need to depend on any other Stanbol module, as such it could also be used with other system using the OSGi http service. Reto On Wed, Nov 9, 2011 at 6:14 PM, Olivier Grisel <[email protected]> wrote: > [Quoted text hidden] > > -- > Olivier > _______________________________________________ > iks-wip mailing list > [email protected] > http://lists.interactive-knowledge.org/cgi-bin/mailman/listinfo/iks-wip > ------------------------------ *Rupert Westenthaler <[email protected]>* *10 November 2011 08:15* To: Reto Bachmann-Gmür <[email protected]> Cc: iks-wip <[email protected]> On 10.11.2011, at 00:07, Reto Bachmann-Gmür wrote: I suggest to have optional query parameters starting with "header_" and followed by the name of the header for any request uri. For this I suggest adding a servlet filter that looks for such query parameters and forwards the http request to the chain with the request header set to the value of the query parameters. Such a module would not need to depend on any other Stanbol module, as such it could also be used with other system using the OSGi http service. Sounds like a good Idea. One problem might be that Servlet Filters are not supported by the default OSGI HttpService [1]. Therefore the registration of Filter is OSGI platform specific (e.g the ExtHttpService in the case of Apache Felix [2]). An other option may be the use of PaxWeb [3]. any experiences? Rupert BTW: I do already use Filters based on the Apache Felix ExtHttpService for registering SolrDispatchFilters - so a Solution that works independent of the used OSGI platform would also be great for this functionality [1] http://www.osgi.org/javadoc/r4v42/org/osgi/service/http/HttpService.html [2] http://felix.apache.org/site/apache-felix-http-service.html#ApacheFelixHTTPService-UsingtheExtHttpService [3] http://team.ops4j.org/wiki//display/paxweb/Pax+Web Reto On Wed, Nov 9, 2011 at 6:14 PM, Olivier Grisel <[email protected]> wrote: > I think we could indeed have dual content type negotiation handling. > For instance by using the a "format" query parameter if there and > falling back to the HTTP "Accept:" header if no "format" query > parameter is provided. > > BTW if we decide to go this we should discuss this on the stanbol-dev > mailing list. > > -- > Olivier > ------------------------------ *Reto Bachmann-Gmür <[email protected]>**10 November 2011 10:53* To: Rupert Westenthaler <[email protected]> Cc: iks-wip <[email protected]> On Thu, Nov 10, 2011 at 8:15 AM, Rupert Westenthaler < [email protected]> wrote: > > On 10.11.2011, at 00:07, Reto Bachmann-Gmür wrote: > > I suggest to have optional query parameters starting with "header_" and > followed by the name of the header for any request uri. For this I suggest > adding a servlet filter that looks for such query parameters and forwards > the http request to the chain with the request header set to the value of > the query parameters. Such a module would not need to depend on any other > Stanbol module, as such it could also be used with other system using the > OSGi http service. > > Sounds like a good Idea. > > One problem might be that Servlet Filters are not supported by the default > OSGI HttpService [1]. Therefore the registration of Filter is OSGI platform > specific (e.g the ExtHttpService in the case of Apache Felix [2]). An other > option may be the use of PaxWeb [3]. > I suggest we just register a javax.servlet.*Filter* service (whiteboard pattern), I think this works both with felix and with pax-web. Cheers, Reto > > any experiences? > Rupert > > BTW: I do already use Filters based on the Apache Felix ExtHttpService for > registering SolrDispatchFilters - so a Solution that works independent of > the used OSGI platform would also be great for this functionality > > [1] > http://www.osgi.org/javadoc/r4v42/org/osgi/service/http/HttpService.html > [2] > http://felix.apache.org/site/apache-felix-http-service.html#ApacheFelixHTTPService-UsingtheExtHttpService > [3] http://team.ops4j.org/wiki//display/paxweb/Pax+Web > > Reto > > On Wed, Nov 9, 2011 at 6:14 PM, Olivier Grisel <[email protected]> wrote: > >> I think we could indeed have dual content type negotiation handling. >> For instance by using the a "format" query parameter if there and >> falling back to the HTTP "Accept:" header if no "format" query >> parameter is provided. >> >> BTW if we decide to go this we should discuss this on the stanbol-dev >> mailing list. >> >> -- >> Olivier >> _______________________________________________ >> iks-wip mailing list >> [email protected] >> http://lists.interactive-knowledge.org/cgi-bin/mailman/listinfo/iks-wip >> > > > _______________________________________________ > iks-wip mailing list > [email protected] > http://lists.interactive-knowledge.org/cgi-bin/mailman/listinfo/iks-wip > >
