Currently, wikidata.org/entity/Q12345 triggers a 303 redirect to wikidata.org/wiki/Special:EntityData/Q12345, which then applies content negotiation and then triggers another 303 redirect to wikidata.org/wiki/Special:EntityData/Q12345.xyz (or to wikidata.org/wiki/Q12345 if appropriate).
If wikidata.org/entity/Q12345 would use an internal rewrite (or proxy) to request wikidata.org/wiki/Special:EntityData/Q12345, only one 303 redirect would be sent to the client. That would better match what is proposed in <http://www.w3.org/TR/cooluris/#r303gendocument>.
Current sequence (with T119532 fixed):
```
> wget -S https://www.wikidata.org/entity/Q36661 2>&1 | egrep '^ *HTTP|^ *Location'
HTTP-Anforderung gesendet, warte auf Antwort...
HTTP/1.1 303 See Other
Location: https://www.wikidata.org/wiki/Special:EntityData/Q36661
HTTP-Anforderung gesendet, warte auf Antwort...
HTTP/1.1 303 See Other
Location: https://www.wikidata.org/wiki/Special:EntityData/Q36661.json
HTTP-Anforderung gesendet, warte auf Antwort...
HTTP/1.1 200 OK
```
Proposed sequence:
```
> wget -S https://www.wikidata.org/entity/Q36661 2>&1 | egrep '^ *HTTP|^ *Location'
HTTP-Anforderung gesendet, warte auf Antwort...
HTTP/1.1 303 See Other
Location: https://www.wikidata.org/wiki/Special:EntityData/Q36661.json
HTTP-Anforderung gesendet, warte auf Antwort...
HTTP/1.1 200 OK
```
NOTE: we can only rewrite (or proxy) from the /entity/Q... path if we are //sure// that the target URL sill still trigger a redirect (or error). We should //never// return content from the /entity/ path, to avoid cache pollution and confusion about subject URI and document URL. 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.