You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose describing the text/perf-marker-stream format as a stream of individual reports.
Each report is "opened" by a single line - indicating the report's type - followed by a list of properties in the Key . ":" . Value format (with optional spaces) and then finished by a single line containing End.
There would be a Performance Marker Report type, starting with a Perf Marker line and a Summary Report type starting either with Success or Failure .*.
Properties and their semantics are then clearly related to the report type.
Of course this primarily affects naming and structure of the specification, the only effect on the wire protocol would be to (optionally?) add an End line to conclude the summary report.
This simplifies the description. Therefore, I think updating the overall description, according to this description is generally "a good idea", but I think care must be taken that we remain backwards compatible and acknowledge currently available formats.
The text was updated successfully, but these errors were encountered:
whether to add an End line to conclude the summary report/ancillary lines. I'm in favour of this change to bring the format in line with the progress markers.
My concern here would be that we should try to avoid making changes that break existing servers. We should only do this if there's no other way.
So, we perhaps this could be added as an optional behaviour: a server MAY omit the final End for the final/summary event, or perhaps SHOULD.
The final End is somewhat redundant, as the end of the stream also identifies that no further information is coming (i.e., chunked encoding sending a zero-length block to indicate the end of the stream).
However, it's not complete redundant. The TCP connection could be prematurely closed, which risks that information was lost. This scenario would be identified by the HTTP client not receiving the final empty block from chunked encoding. However, the code processing the event stream might not have access to this information (whether the TCP connection was closed prematurely). In this case, sending End could help identify that information may have been lost.
In #1, @pskopnik observed that "the ancillary lines match the format of the progress markers"
@pskopnik further writes:
This simplifies the description. Therefore, I think updating the overall description, according to this description is generally "a good idea", but I think care must be taken that we remain backwards compatible and acknowledge currently available formats.
The text was updated successfully, but these errors were encountered: