daniel added a comment.
I have reproduced this with wget:
wget --header 'Accept: text/html, application/xhtml+xml, image/jxr, */*' -q
-S -O /dev/null http://www.wikidata.org/wiki/Special:EntityData/Q550207 2>&1 |
egrep '^ *HTTP/|^ *Location'
This does indeed redirect to the JSON version,
https://www.wikidata.org/wiki/Special:EntityData/Q550207.json
When the */* part is removed from the Accept header, the redirect goes to the
HTTP version:
wget --header 'Accept: text/html, application/xhtml+xml, image/jxr' -q -S
-O /dev/null http://www.wikidata.org/wiki/Special:EntityData/Q550207 2>&1 |
egrep '^ *HTTP/|^ *Location'
...goes to https://www.wikidata.org/wiki/Q550207 as expected.
The issue seems to be that the */* (match anything) option is chosed over the
text/http option. As per the spec, **this is not a bug**: The types in the
Accept header are not given in the order of preference, but should use q=n
parameters to indicate which type is preferred. E.g.
wget --header 'Accept: text/html; q=1, application/xhtml+xml; q=0.8,
image/jxr; q=0.5, */*; q=0.1' -q -S -O /dev/null
http://www.wikidata.org/wiki/Special:EntityData/Q550207 2>&1 | egrep '^
*HTTP/|^ *Location'
...correctly resolves to https://www.wikidata.org/wiki/Q550207 as expected.
According to the spec, if no q parameter is given, q=1 is assumed, see
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1: //The default
value is q=1//. So if */* with no q parameters is present in the header, the
server is free to respond with //any// kind of content.
Apache has a workaround for buggy browsers that send */* with no q parameter:
https://httpd.apache.org/docs/current/content-negotiation.html: //If the
Accept: header contains no q factors at all, httpd sets the q value of "*/*",
if present, to 0.01 to emulate the desired behavior. It also sets the q value
of wildcards of the format "type/*" to 0.02 (so these are preferred over
matches against "*/*". If any media type on the Accept: header contains a q
factor, these special values are not applied, so requests from browsers which
send the explicit information to start with work as expected.//
We may want to do that same, but perhaps MS could get their sh*t together for
once.
TASK DETAIL
https://phabricator.wikimedia.org/T133314
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: daniel, Nikki, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
