Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When using JSON-LD in a browser it is impossible to discover the Base IRI after a redirect #316

Open
graingert opened this issue Feb 5, 2014 · 7 comments

Comments

@graingert
Copy link

When using JSON-LD in a browser (XMLHttpRequest) it is impossible to discover the Base IRI after a redirect because the XHR object hides the final URL of the resource.

This means documents without an explicit base URI cannot be resolved into triples in a browser

@dlongley
Copy link
Member

dlongley commented Feb 5, 2014

True. There may be a messy iframe workaround that could grab the final URL, but I'm not sure.

@graingert
Copy link
Author

But if you

<iframe src="http://id.ecs.soton.ac.uk/person/1650" />

Then it will redirect to http://www.ecs.soton.ac.uk/people/wh rather than http://rdf.ecs.soton.ac.uk/person/1650 or http://json-ld.ecs.soton.ac.uk/person/1650
then it will end up on "http://id.ecs.soton.ac.uk/person/1650" and not .ecs.soton.ac.uk/person/1650

because the iframe dictates the content type and will break content negotiation accordingly

@dlongley
Copy link
Member

dlongley commented Feb 5, 2014

Yeah, this is a general problem we discussed while working on the spec a while back -- one that we ultimately decided we'd have to live with. Our hope is that a future spec allows redirects to be disabled (and thus implemented in app) or that a final URL property is made available.

See:

http://stackoverflow.com/questions/3820663/is-it-possible-for-xhr-head-requests-to-not-follow-redirects-301-302/3820753#3820753

Possible iframe workaround:

http://stackoverflow.com/questions/16430901/get-final-url-from-xhr-object-after-redirect

But, as you noted, content-negotiation is up to the iframe -- and even if it works and you get back application/ld+json, current browsers don't know how to display that so a download dialog box is opened instead of displaying the document and allowing the URL to be captured.

@graingert
Copy link
Author

Would it be possible to add a reference to http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/#notcovered and some text describing this problem in the http://www.w3.org/TR/json-ld/#base-iri section?

@msporny
Copy link
Member

msporny commented Feb 5, 2014

@graingert http://www.w3.org/TR/json-ld/ is frozen, there will be no updates or additions to the specification for a long time (2+ years). We could add what you mention to the Errata, but even then, it's not an error. We could update the live version of the spec w/ this information (which is probably what we should do): http://www.w3.org/TR/json-ld/ (or the API document)

@lanthaler
Copy link
Member

Hmm... it’s a limitation of JavaScript in the browser. I don’t see that as an error of JSON-LD. Maybe you/we should file an issue against XMLHttpRequest2 instead!?

@graingert
Copy link
Author

Yes it's a limitation of JS in the browser, but that's the main use of JSON documents.

@gkellogg gkellogg removed the on-hold label Apr 9, 2018
@gkellogg gkellogg added this to the JSON-LD 1.1 milestone Apr 9, 2018
gkellogg added a commit that referenced this issue Apr 20, 2018
gkellogg added a commit that referenced this issue Apr 21, 2018
@gkellogg gkellogg added the api label Apr 21, 2018
@gkellogg gkellogg self-assigned this Apr 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants