[Wikidata-bugs] [Maniphest] [Commented On] T119536: [RFC] should wikidata.org/entity/Q12345 do content negotiation, instead of redirecting to wikidata.org/wiki/Special:EntityData/Q36661 first?

2016-11-10 Thread elf-pavlik 
elf-pavlik added a comment.
So, /entity/Q1234.ttl must not be rewritten but redirected to /wiki/Special:EntityData/Q1234.ttl, since that will return data. To ensure this, a magic parameter could be passed, something like force-redirect=true, which would force Special:EntityData to send a redirect to the canonical URL instead of serving content directly.

/entity/Q1234.ttl currently does NOT appear in chain of redirects from /entity/Q1234 and it doesn't seem to serve any purpose to have URIs like /entity/Q1234.ttl appearing anywhere all together.

Currently /entity/Q1234 redirects to /wiki/Special:EntityData/Q1234 which seems to handle content negotiation and redirects to /wiki/Special:EntityData/Q1234.ttl or /wiki/Special:EntityData/Q1234.json.

Preferably /entity/Q1234 will directly do 303 redirect to /wiki/Special:EntityData/Q1234.ttl or /wiki/Special:EntityData/Q1234.json. Which should work if you proxy pass to  /wiki/Special:EntityData/Q1234 which seems to handle content negotiation and do 303 redirect (plus should have CORS headers set)

Once again, /entity/Q1234.ttl or /entity/Q1234.json don't seem to have any purpose and such URIs should never appear anywhrere.TASK DETAILhttps://phabricator.wikimedia.org/T119536EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: elf-pavlikCc: hoo, elf-pavlik, JanZerebecki, Aklapper, StudiesWorld, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, fbstj, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T119536: [RFC] should wikidata.org/entity/Q12345 do content negotiation, instead of redirecting to wikidata.org/wiki/Special:EntityData/Q36661 first?

2016-11-10 Thread elf-pavlik 
elf-pavlik added a comment.
Correct, +1 removing redirect to the 'in-between' page and after 301 to HTTPS doing single 303 redirect directly to content negotiated representation where in your case URI ends with .ttl, .json etc.TASK DETAILhttps://phabricator.wikimedia.org/T119536EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: elf-pavlikCc: hoo, elf-pavlik, JanZerebecki, Aklapper, StudiesWorld, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, fbstj, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T150290: add CORS to all redirecs in chain from https://www.wikidata.org/entity/{Q...}

2016-11-10 Thread elf-pavlik 
elf-pavlik added a comment.
But that would be semantically dirty. As far as I understand, it's best practice to not serve data directly when resolving a concept URI, but to redir3ect to a document URL first.

I understood that it would work this way

URI of a thing: http://www.wikidata.org/entity/Q1141085
would HTTP 303 redirect to the document with the representation in requested content type
https://www.wikidata.org/wiki/Special:EntityData/Q1141085.ttl

Currently as explained in  T119536 you have two 303 redirects. If you proxy pass the URI of a thing (instead of the first 303 redirect) to Special:EntityData page which seems to handle content negotiation. It should still 303 redirect you (currently the second 303 redirect)  to the document with requested content type, so this case: https://www.w3.org/TR/cooluris/#r303uriTASK DETAILhttps://phabricator.wikimedia.org/T150290EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, elf-pavlikCc: thiemowmde, gerritbot, hoo, daniel, Aklapper, elf-pavlik, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T150290: add CORS to all redirecs in chain from https://www.wikidata.org/entity/{Q...}

2016-11-09 Thread elf-pavlik 
elf-pavlik added a comment.
A potential solution I could think of would be to ProxyPass the /entity/ (and related) redirects to the special page. That would also solve us T119536 for free, as far as I can tell.

brilliant!

so we should get

curl -IL http://www.wikidata.org/entity/Q1141085 -H "Accept: text/turtle"

HTTP/1.1 303 See Other
Location: https://www.wikidata.org/wiki/Special:EntityData/Q1141085.ttl
Access-Control-Allow-Origin: *



HTTP/1.1 200 OK
Content-Type: text/turtle; charset=UTF-8
Access-Control-Allow-Origin: *TASK DETAILhttps://phabricator.wikimedia.org/T150290EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: elf-pavlikCc: gerritbot, hoo, daniel, Aklapper, elf-pavlik, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T119536: [RFC] should wikidata.org/entity/Q12345 do content negotiation, instead of redirecting to wikidata.org/wiki/Special:EntityData/Q36661 first?

2016-11-09 Thread elf-pavlik 
elf-pavlik added a comment.
+1 proposal of removing second 303, which seems matching https://www.w3.org/TR/cooluris/#r303uri

F4710362: 303.pngTASK DETAILhttps://phabricator.wikimedia.org/T119536EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: elf-pavlikCc: elf-pavlik, JanZerebecki, Aklapper, StudiesWorld, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, fbstj, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T150290: add CORS to all redirecs in chain from https://www.wikidata.org/entity/{Q...}

2016-11-09 Thread elf-pavlik 
elf-pavlik added a comment.
This issue looks also related to https://phabricator.wikimedia.org/T119536 which I understand proposes removing the second 303 which I +1

Where do you set CORS header for https://www.wikidata.org/wiki/Special:EntityData/Q1141085.ttl or https://www.wikidata.org/wiki/Special:EntityData/Q1141085.json ? Those responses have Access-Control-Allow-Origin: *TASK DETAILhttps://phabricator.wikimedia.org/T150290EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: elf-pavlikCc: hoo, daniel, Aklapper, elf-pavlik, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T150290: add CORS to all redirecs in chain from https://www.wikidata.org/entity/{Q...}

2016-11-08 Thread elf-pavlik 
elf-pavlik created this task.elf-pavlik added a project: Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONI work on developing few new Solid web applications which run in a web browser and get data via CORS. They use linked data and I would like to use wikidata as common reference in similar way as people often use DBpedia.

Taking as example http://www.wikidata.org/entity/Q1141085

fetch('http://www.wikidata.org/entity/Q1141085')

Chrome 54

Fetch API cannot load https://www.wikidata.org/entity/Q1141085. Redirect from 'https://www.wikidata.org/entity/Q1141085' to 'https://www.wikidata.org/wiki/Special:EntityData/Q1141085' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Firefox 49

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.wikidata.org/entity/Q1141085. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

checking from CLI with curl

curl -IL http://www.wikidata.org/entity/Q1141085 -H "Accept: text/turtle"

HTTP/1.1 301 Moved Permanently
Location: https://www.wikidata.org/entity/Q1141085



HTTP/1.1 303 See Other
Location: https://www.wikidata.org/wiki/Special:EntityData/Q1141085



HTTP/1.1 303 See Other
Location: https://www.wikidata.org/wiki/Special:EntityData/Q1141085.ttl



HTTP/1.1 200 OK
Content-Type: text/turtle; charset=UTF-8
Access-Control-Allow-Origin: *

So while the final 200 OK response includes CORS header Access-Control-Allow-Origin: *, in browser client which starts from the URI denoting the entity: http://www.wikidata.org/entity/Q1141085 can NOT follow all the redirects to arrive to that response

Daniel Kinzler suggested me to report this issue here
https://twitter.com/brightbyte/status/795994606282428416TASK DETAILhttps://phabricator.wikimedia.org/T150290EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: elf-pavlikCc: hoo, daniel, Aklapper, elf-pavlik, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs