Closed bscSCORM closed 7 years ago
Wouldn't that also conflict with this:
The Client MUST include the "X-Experience-API-Version" header in every request.
@DavidTPate
The Client MUST include the "X-Experience-API-Version" header in every request. That's a client requirement that was introduced in 0.95, it doesn't apply to 0.9 clients (there are going to be plenty of other 1.0 client requirements that 0.9 clients would break as well).
But perhaps even more clarity could be added here, that since such requests are routed to that prior-version implementation, none of the other requirements in this document would apply. I thought that was implicit in "routed to a fully conformant implementation of the prior version", but I can see now how more clarity there wouldn't hurt.
This does present a bit of a testing challenge, as we've given LRSs some responsibility for validating client requirements. It's going to be hard to tease out the difference between an LRS that's failing to reject version less requests even though it doesn't implement 0.9, and one that properly implements version 0.9 and are just assuming such requests must be for that implementation. We could take care to test this particular requirement by making requests that would be valid xAPI 1.0 requests, but are not valid in 0.9, and leave the header off. Then the correct response would be 400
either way.
+1 "prior version specified in the header" - you could interpret no header as implicitly specifying 0.9 in the header. The proposed change I think captures the intended meaning.
resolved by #984
The reason for this
unless
part is to allow a single endpoint to be backwards compatible with prior versions. Unfortunately, version 0.9 did not include a version header, so to be clear that 0.9 comparability is allowed, we should change this to: