[netconf] RESTCONF error responses when streaming

["Jan Lindblad (jlindbla)" <[e-mail]>]

Hi all,

RFC 8040 has some nice examples of RESTCONF requests that return errors, i.e. invalid-value 400, access-denied 403, in-use 409, etc. But what if the server streams/pipes the output back to the client, and everything looks fine to begin with? 

Let's say the client does a GET /restconf/data/example-jukebox:jukebox/library . In our example here, the library is huge, so the implementation streams back the responses. Half way through, the database chokes on something and shuts down. It's now too late to return operation-failed 412, since the status code is returned in the response header.

Which of the following alternatives best describes the behaviour that the RESTCONF server should implement in the above situation?

a) Simply close the client connection
b) Return a <nc:errors> tag right where the problem is detected, xmlns:nc="urn:ietf:params:xml:ns:yang:ietf-restconf" (assuming XML media type)
b2) Return a "ietf-restconf:errors" tag right where the problem is detected (assuming JSON media type)
c) Provide closing tags/brackets to return to the "top level", then return a <nc:errors>/"ietf-restconf:errors" blurb
d) None of the above
e) No valid reply exists

Looking for general REST answers to this problem, it looks like some people have created a mime-multipart message encoding which allows status codes to be sent in a follow up mime part. Would anything like that be usable in a situation like this?
https://stackoverflow.com/questions/56980068/when-to-write-headers-for-a-streaming-response

Best Regards,
/jan