[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (ODATA-868) Describe HTTP encoding for streamed requests and responses
[ https://issues.oasis-open.org/browse/ODATA-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ralf Handl updated ODATA-868:
-----------------------------
Description:
OData JSON Format has a format parameter for streaming scenarios but does not describe how these messages should be encoded.
Part 1: Protocol, section 9.4 talks about in-stream errors in a format-independent way. Unfortunately we don't define how these should be represented in the JSON format.
Situations where in-stream errors can occur include
- metadata requests in XML or JSON
- data request in JSON or XML
- media resource requests with any content-type
was:
In Part 1: Protocol, section 9.4 we talk about in-stream errors in a format-independent way. Unfortunately we don't define how these should be represented in the JSON format.
Situations where in-stream errors can occur include
- metadata requests in XML or JSON
- data request in JSON or XML
- media resource requests with any content-type
Proposal:
No proposal yet, just a collection of ideas:
Encoding for streamed messages in general
- HTTP/2 has built-in streaming, see https://tools.ietf.org/html/rfc7540#section-5
- HTTP/1.1 has chunked transfer encoding, see https://tools.ietf.org/html/rfc7230#section-4.1
- Both approaches in their raw form are difficult for the recipient because they'd need to parse incomplete JSON objects or arrays
- Use server-driven paging idea and let the sender partition the full message into segments, each of which is a complete JSON object
- With HTTP/2 push the next-link responses to the client; on error just push a 5xx standard OData error response
- with HTTP/1.1 use chunked transfer encoding of a multipart response, one single response per segment, in case of in-stream errors last segment is a 5xx standard OData error response
- the benefit of server-driven paging style responses is that clients can JSON.parse() each part without having to parse incomplete JSON responses when using chunked encoding of a single response with one large JSON object.
Other ideas
- if error occurs, inject invalid character (sequence) in stream to stop parsing on client, then inject format-specific error body
- streaming responses contain a header with a link to a monitor resource where clients can check whether the streamed response ended prematurely due to an error.
- with HTTP/2 server can push response to monitor resource requests to client in case of errors
- with HTTP/1.1 use chunked transfer encoding and send error information in trailing headers, e.g. an odata-error "header" that contains a header-friendly encoded JSON or XML error response
was:
No proposal yet, just a collection of ideas:
- if error occurs, inject invalid character (sequence) in stream to stop parsing on client, then inject format-specific error body
- streaming responses contain a header with a link to a monitor resource where clients can check whether the streamed response ended prematurely due to an error.
- with HTTP/2 server can push response to monitor resource requests to client in case of errors
- with HTTP/1.1 use chunked transfer encoding and send error information in trailing headers, e.g. an odata-error "header" that contains a header-friendly encoded JSON or XML error response
- simulate streaming via server-driven paging and use HTTP/2 to push the next-link responses to the client; on error just push a 5xx error response
- with HTTP/1.1 simulate server push via chunked transfer of a multipart response for server-driven paging, use standard OData error response in case of in-stream errors
- the benefit of server-driven paging style responses is that clients can JSON.parse() each part without having to parse incomplete JSON responses when using chunked encoding of a single response with one large JSON object.
> Describe HTTP encoding for streamed requests and responses
> ----------------------------------------------------------
>
> Key: ODATA-868
> URL: https://issues.oasis-open.org/browse/ODATA-868
> Project: OASIS Open Data Protocol (OData) TC
> Issue Type: Bug
> Components: OData JSON Format
> Affects Versions: V4.0_ERRATA02
> Reporter: Ralf Handl
> Labels: Clarification
> Fix For: V4.01_WD01
>
>
> OData JSON Format has a format parameter for streaming scenarios but does not describe how these messages should be encoded.
> Part 1: Protocol, section 9.4 talks about in-stream errors in a format-independent way. Unfortunately we don't define how these should be represented in the JSON format.
> Situations where in-stream errors can occur include
> - metadata requests in XML or JSON
> - data request in JSON or XML
> - media resource requests with any content-type
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]