From a16919e1f0032cf3722f7d21bbd37594e969e8c2 Mon Sep 17 00:00:00 2001
From: Eric Gribkoff <ericgribkoff@google.com>
Date: Mon, 10 Jul 2017 14:55:17 -0700
Subject: [PATCH] Update compression test for languages without compression bit
---
doc/interop-test-descriptions.md | 33 ++++++++++++++++++--------------
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/doc/interop-test-descriptions.md b/doc/interop-test-descriptions.md
index b040621f88..0ee2cae2bd 100644
--- a/doc/interop-test-descriptions.md
+++ b/doc/interop-test-descriptions.md
@@ -183,7 +183,8 @@ the `response_compressed` boolean.
Whether compression was actually performed is determined by the compression bit
in the response's message flags. *Note that some languages may not have access
-to the message flags*.
+to the message flags, in which case the client will be unable to verify that
+the `response_compressed` boolean is obeyed by the server*.
Server features:
@@ -218,10 +219,10 @@ Procedure:
```
Client asserts:
* call was successful
- * when `response_compressed` is true, the response MUST have the
- compressed message flag set.
- * when `response_compressed` is false, the response MUST NOT have
- the compressed message flag set.
+ * if supported by the implementation, when `response_compressed` is true,
+ the response MUST have the compressed message flag set.
+ * if supported by the implementation, when `response_compressed` is false,
+ the response MUST NOT have the compressed message flag set.
* response payload body is 314159 bytes in size in both cases.
* clients are free to assert that the response payload body contents are
zero and comparing the entire response message against a golden response
@@ -304,8 +305,8 @@ Procedure:
}
}
```
- If the call fails with `INVALID_ARGUMENT`, the test fails. Otherwise, we
- continue.
+ If the call does not fail with `INVALID_ARGUMENT`, the test fails.
+ Otherwise, we continue.
1. Client calls `StreamingInputCall` again, sending the *compressed* message
@@ -377,7 +378,13 @@ Client asserts:
### server_compressed_streaming
This test verifies that the server can compress streaming messages and disable
-compression on individual messages.
+compression on individual messages, expecting the server's response to be
+compressed or not according to the `response_compressed` boolean.
+
+Whether compression was actually performed is determined by the compression bit
+in the response's message flags. *Note that some languages may not have access
+to the message flags, in which case the client will be unable to verify that the
+`response_compressed` boolean is obeyed by the server*.
Server features:
* [StreamingOutputCall][]
@@ -407,15 +414,14 @@ Procedure:
Client asserts:
* call was successful
* exactly two responses
- * when `response_compressed` is false, the response's messages MUST
- NOT have the compressed message flag set.
- * when `response_compressed` is true, the response's messages MUST
- have the compressed message flag set.
+ * if supported by the implementation, when `response_compressed` is false,
+ the response's messages MUST NOT have the compressed message flag set.
+ * if supported by the implementation, when `response_compressed` is true,
+ the response's messages MUST have the compressed message flag set.
* response payload bodies are sized (in order): 31415, 92653
* clients are free to assert that the response payload body contents are
zero and comparing the entire response messages against golden responses
-
### ping_pong
This test verifies that full duplex bidi is supported.
@@ -1095,4 +1101,3 @@ Discussion:
Ideally, this would be communicated via metadata and not in the
request/response, but we want to use this test in code paths that don't yet
fully communicate metadata.
-
--
GitLab