TS-0009: Possibly wrong presence of attributeList in CONTENT
There is an issue that TS-0009 might prevent to determine the correct reason why a CREATE or UPDATE request has wrong a CONTENT request parameter.
This issue is related to issue #162 .
The following scenario describes the handling of an invalid request. Normally, the attributeList parameter shall only be present in a RETRIEVE parameter. Under certain circumstances (ie. when the attributeList parameter is also present in a CREATE or UPDATE request), the mapping rules in the http binding specification force an overwrite of the actual CONTENT request parameter.
Further background: Normally, the attributeList would be an extra data structure of CONTENT. However, though it is not forbidden, a http GET (ie. RETRIEVE) operation must not have a content body that transports any semantics.
Scenario
- A CSE receives a CREATE or an UPDATE request via the http binding.
- The originator has specified multiple (!) attributes in the attributeList (atrl) URL parameter.
- There are different handlings on passing a single or multiple attributes for a partial RETRIEVE:
- A single attribute is internally added to the to attribute, e.g.
<target>#attribute
- Multiple attributes are added to a list of attributes as the m2m:attributeList element of a request content.
- Perhaps it should be further discussed why this different handlings have been defined, and whether it would make sense to simplify this behaviour.
- A single attribute is internally added to the to attribute, e.g.
- There are different handlings on passing a single or multiple attributes for a partial RETRIEVE:
- The attributeList with these attributes is now added as the request CONTENT, ie. it replaces the existing CONTENT parameter and its content.
- After doing its work the http binding passes the modified request to the CSE. The CSE now during validation detects an invalid structure in the CONTENT parameter and returns a BAD_REQUEST error.
- However, the error handling could be wrong or misleading since the original CONTENT's content might have been correct or contain different problems, though the original request was not (since it contained the attributeList parameter).
Possible Solution for discussion
The http binding shall not overwrite the CONTENT parameter if it is already be present in the request. In this case the attributeList is removed from the original request.
This, of course, leads to the problem that an invalid request is processed as correct.
Another solution would be that the http binding does do a minimal validation, and is able to return a BAD_ERROR error.
Note
It should be checked whether the CoAP binding has the same problems.