xAPI 2.0.0, PUT or POST w/ excess multipart sections

[raif-s-naffah]

hi there,

while running conformance tests for a version 2.0.0 server, i see that one of the failing tests is titled An LRS rejects with error code 400 Bad Request, a PUT or POST Request which has excess multi-part sections that are not attachments. (Communication 1.5.1.s1.b2, Data 2.4.11, XAPI-00128).

besides the fact that i cannot see in the xapi-base-standard-documentation any such sections, i previously asked a question and got a response here that indirectly implied (a) excess multipart sections may be included in the request and (b) the LRS should match match those to actual Attachment object type instance based on the section(s)' Content-Length and X-Experience-API-Hash headers.

furthermore, to my knowledge the LRS related document has no such SHALL requirement.

would much appreciate it if somebody can clarify this and point me to the appropriate 2.0.0 specifications section(s) related to this issue.

thanks in anticipation + cheers;
rsn

[integralla]

Hi Raif,

In the response that you referenced above, I did not mean to imply that excess parts can be included in the request. The specification is not very explicit on this exact point but I think it's implied by the following requirement:

Requirements for Attachment Statement Batches

Each additional part contains the raw data for an Attachment and forms a logical part of the Statement.

The particular conformance test you're referring to here is sending a request with four parts where the forth part is not referenced by any of the attachments associated with the statement provided in the first part.

[raif-s-naffah]

hi Andrew,

thanks for taking the time to respond! much appreciated.

may i suggest that a note or clearer wording be added to the specifications, especially when there is a test specifically designed to ensure conformance for candidate implementations.

[integralla]

may i suggest that a note or clearer wording be added to the specifications, especially when there is a test specifically designed to ensure conformance for candidate implementations.

I think the process for that would be to open an issue under the following project:
https://opensource.ieee.org/xapi/xapi-base-standard-documentation/-/blob/main/CONTRIBUTING.md

[raif-s-naffah]

hi Andrew,

noted + thanks. i assume you mean here where i already have 2 open questions?

---

before i close this one however, would appreciate it if you can confirm my understanding so far of the handling of Statements resource:

a conformant LRS...

R1. shall reject PUT and POST requests w/ Content-Type other then application/json or multipart/mixed with status 400.

R2. shall reject PUT and POST multipart/mixed requests with status 400 if (a) the first part does not have application/json as its Content-Type, or (b) if any of the other parts does not have a binary Content-Transfer-Encoding. this last part enforces the shall statement in 2

shall include a Content-Transfer-Encoding parameter with a value of binary in each part's header after the first (Statements) part.

and not the should statement in 3

When receiving a PUT or POST with a document type of multipart/mixed, an LRS should assume a Content-Transfer-Encoding of binary for Attachment parts.

i.e. the header in question must be present and equal to binary.

a PUT or POST request w/ Content-Type multipart/mixed may include attachments. if N is the total number of Attachment objects specified in the Statement(s) contained in the request which do not have a fileUrl property set, and M is the total number of parts specified in those N Statements minus 1, a conformant LRS...

R3. shall reject with status 400 requests that have M > N.

R4. when including attachments in a multipart/mixed PUT or POST request, the contents of an attachment should be included once.

a conformant LRS...

R5. shall match the actual attachment part to the Attachment object using, in that order: the Content-Type header if present, the SHA-2 hash of the contents, and the length in bytes. when matching the hash the LRS must compute the hash independently and not rely on the presence and value of an X-Experience-API-Hash header.

[integralla]

i assume you mean here where i already have 2 open questions?

Yes. Note, I am not part of the working group and don't have any insight into how issues are triaged, etc. I'm just an xAPI developer myself, and I'm just an informal contributor here.

I'm not going to try to comment on your rephrasing of the requirements because there's too much that needs to be addressed/clarified with that approach. I'd encourage you to ask for clarification regarding specific phrases of the spec, rather than a request to validate your rephrasing.

I'll just one note here regarding the portions of the specification that refer to the Content-Transfer-Encoding header that you quoted. You can find some history on this in the following two issues:

• Attachments should specify binary encoding xAPI-Spec#107
• Statement Batches: LRS Requirements Should Be as Strict as Request Requirements xAPI-Spec#917

[raif-s-naffah]

thanks Andrew!

the issues you pointed to relate to a different version of xAPI than the 2.0.0 specs (i'm trying to implement) and conformance tests (i'm trying to pass).

i'll open a new Issue in the IEEE repo for this specific question.