Nevalicori added a comment.

Hi @Lucas_Werkmeister_WMDE ,

Not quite an assumption per se; HTTP is stateless, so it doesn't really matter what kind of redirect you used to arrive at /Q1.ttl; if that ends up being the Request-URI, then that's the URL which needs to appear in the document for an automated processor to be able to interpret licensing statements properly.

With respect to which HTTP status code is actually correct… that's a slightly different issue; and it's a little tricky because there are very few LOD clients out there against which to baseline behaviour. However, in the past where I've implemented them, whether a redirect is a 301/302 or a 303 does necessarily influence behaviour to an extent:

you request <id-of-thing>:

a) if the response is 301/302, the redirect target is interpreted as an alias for <id-of-thing> (i.e., you're potentially redirecting the concept, and so the target should be added to the list of candidate URIs to look for in the document you eventually retrieve)

b) if the response is 303, the redirect target is the URL of a document containing data about <id-of-thing>

In the Wikidata case, (b) happens in the redirect from /entity/Q1 to /Special:EntityData/Q1; the complicating factor is that Wikidata is then redirecting a second time, after content negotiation. In principle, I'd be inclined to agree that 302 Found with Vary: Accept would be the correct response here (because /Q1 is, conditional upon the value of the Accept header, an alias for /Q1.ttl). However, I have no idea how processors would behave in that scenario. It's probably fine, though :)


TASK DETAIL
https://phabricator.wikimedia.org/T73991

EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Nevalicori
Cc: Addshore, Lucas_Werkmeister_WMDE, Smalyshev, Nevalicori, Wikidata-bugs, Lydia_Pintscher, daniel, Dinadineke, Nandana, tabish.shaikh91, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, merbst, LawExplorer, _jensen, aude, TheDJ, Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to