Your quote is missing the first part of the sentence. To avoid unnecessarily committing an RPC on the client, gRPC servers *must* > delay sending Response-Headers until the server's first response (a > Length-Prefixed-Message) is to be sent on the stream.
The intent was "in order to achieve A, you must do B.", not you must always do B. If Response-Headers are always immediately sent, retries will never be possible. Hence, gRPC servers *"must"* delay the Response-Header to avoid unnecessarily committing an RPC. Using *should* here instead would almost convey the same message, but needs further qualification. How about: If Response-Headers are always immediately sent, retries will never be > possible. Hence, gRPC servers should delay the Response-Header to avoid > unnecessarily committing an RPC. Once Response-Headers are sent, retries > will not be possible. > My intent was not to say we are changing the wire spec to *must. * But Response-Headers constitute a response to the client and, if your gRPC server sends them eagerly, retries will never occur. This is allowable by the wire spec but should somehow be noted - somewhat strongly - in the retry specification. On Thu, Mar 2, 2017 at 4:29 PM, Eric Anderson <[email protected]> wrote: > The spec was updated today to say: > >> gRPC servers *must* delay sending Response-Headers until the server's >> first response (a Length-Prefixed-Message) is to be sent on the stream. > > > Why is this *must*? It was changed from *should*, so this seems > intentional. Java can't support *must*. > > On Thu, Mar 2, 2017 at 9:03 AM, Eric Anderson <[email protected]> wrote: >> >> The wire spec *almost* says it: "Trailers-Only is permitted for calls >>>> that produce an immediate error" (https://github.com/grpc/grpc/ >>>> blob/master/doc/PROTOCOL-HTTP2.md). Do you want this changed in the >>>> wire spec itself or is the inclusion in the gRFC for retries sufficient? >>>> >>> >>> I think it would be good to also change the wire spec doc. We should do >>> something like changing "is permitted" to "SHOULD be used". We may even >>> want to specifically mention that this is important for retry functionality >>> to work right. >>> >> >> Changing to 'should' sounds fine. Although maybe there should be a note >> that clients can't decide if something is an 'immediate error' so there >> must not be any validation for it client-side. >> > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CALUXJ7hGct2GioJwr-35q-oqEo%2BoE7TG3JLntqCBK_hN1-iBYg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
