Closed pivotal-marcela-campo closed 3 years ago
Thanks for raising this @pivotal-marcela-campo. Yeah it looks like 202 malformed is missing.
Out of interest, what is the current behaviour of CF for malformed 202 responses? And @jhvhs what about service-catalog?
As a side note, what constitutes a malformed response is interesting here, since the 202 provision/bind response fields are optional. As we allow additional non-spec keys, the only malformed responses here would non application/json
or using a key with an invalid value or type. E.g. {"operation": true}. Is that what you had in mind or are there other cases?
Also, I think we should make 202 malformed response consistent with how we represent 201 malformed, with different row entries for provision and binding instead of a single row.
Thanks @Samze for the feedback. I've made the suggested change.
Current CF behaviour for binding/provisioning is to perform OM mitigation under this scenario (for both v2
and v3
api versions).
It seems we are inline as to what constitutes a malformed response. For async binding
and provisioning
(202 responses) we are considering a malformed response as one that is either not JSON or doesn't adhere to the expected JSON schema (example schema).
Do let me know if you need more information!
:+1:
…the platform would not be able to poll if the broker requires an operation to be sent back in the last_operation request.
What is the problem this PR solves? As from OSB API spec 2.14 brokers may return an operation id for async requests. That operation id should be included in subsequent requests to fetch last_operation. In the event of a 202 response, if the response body is malformed, then the platform cannot get the operation id to send back when fetching last_operation and then would find itself unable to keep track of the operation. Resources might have been created by the broker and these would need to be cleaned up.
Checklist: