You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is specifically of note because you can put full documents in the IRL attachment field. The following javascript code will parse the field in a way that is expected, and makes it indistinguishable for most systems that blindly pass through the fileUrl value into a javascript Fetch statement.
You can even run the above in your debugging tools. What I cannot really tell is if this actually violates the spec. "data" is a valid scheme and works transparently in javascript, and with some minor special handling in python as long as the library is setup to parse the standard. Is it a violation of the spec to include a RFC-2397 compliant blob of data in the Attachment's fileUrl field?
If not that seems like a way to accidentally blow up storage expectations on servers recording the xapi entries.
The text was updated successfully, but these errors were encountered:
You raise an interesting point. The spec does not prevent an LRS from rejecting statements that it considers too large.
From the spec:
None of these requirements contradict the idea that the LRS is also allowed to be configurable to reject requests and respond or behave differently on the basis of conditions that are out of scope this specification.
It might be worth reading issue #1088 the response from @brianjmiller is particularly useful.
The following is a xAPI json blob that validates just fine in https://lrs.adlnet.gov/statementvalidator .
This is specifically of note because you can put full documents in the IRL attachment field. The following javascript code will parse the field in a way that is expected, and makes it indistinguishable for most systems that blindly pass through the fileUrl value into a javascript Fetch statement.
You can even run the above in your debugging tools. What I cannot really tell is if this actually violates the spec. "data" is a valid scheme and works transparently in javascript, and with some minor special handling in python as long as the library is setup to parse the standard. Is it a violation of the spec to include a RFC-2397 compliant blob of data in the Attachment's fileUrl field?
If not that seems like a way to accidentally blow up storage expectations on servers recording the xapi entries.
The text was updated successfully, but these errors were encountered: