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
Currently, the reference server and reference client make additional assertions about the peer's protocol implementation by examining wire-level details and checking for well-formedness. But some of the checks could really be considered "recommendations", not "requirements", largely in the spirit of the robustness principle (be strict about what you emit, but be lenient about what you accept). For example, if the "grpc-status-details-bin" trailer value uses base64 padding, the reference client complains with an error. The spec states, however, that servers should emit unpadded values, not must. Currently, these checks cause test cases to fail.
Ideally, each of these extra assertions could be given a unique name and that name could then be used to disable them, either in a config file or via command-line flag. This would allow us to more clearly separate required vs. recommended checks and to allow implementations that only do what's required (and not what's recommended) to still pass tests.
The text was updated successfully, but these errors were encountered:
Currently, the reference server and reference client make additional assertions about the peer's protocol implementation by examining wire-level details and checking for well-formedness. But some of the checks could really be considered "recommendations", not "requirements", largely in the spirit of the robustness principle (be strict about what you emit, but be lenient about what you accept). For example, if the "grpc-status-details-bin" trailer value uses base64 padding, the reference client complains with an error. The spec states, however, that servers should emit unpadded values, not must. Currently, these checks cause test cases to fail.
Ideally, each of these extra assertions could be given a unique name and that name could then be used to disable them, either in a config file or via command-line flag. This would allow us to more clearly separate required vs. recommended checks and to allow implementations that only do what's required (and not what's recommended) to still pass tests.
The text was updated successfully, but these errors were encountered: