Considering that the goal seems to be avoiding committing the RPC until the server-side application has started processing the call, perhaps we could say something like "gRPC servers should delay the Response-Header until the first response message *or until the application code chooses to send headers*".
On Thu, Mar 2, 2017 at 4:46 PM 'Eric Gribkoff' via grpc.io < grpc-io@googlegroups.com> wrote: > 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 <ej...@google.com> 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 <ej...@google.com> 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 grpc-io+unsubscr...@googlegroups.com. > To post to this group, send email to grpc-io@googlegroups.com. > 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 > <https://groups.google.com/d/msgid/grpc-io/CALUXJ7hGct2GioJwr-35q-oqEo%2BoE7TG3JLntqCBK_hN1-iBYg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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/CAPK2-4drp42Cbe3%3DEBJybKamHijf9W5tKbn_yByZprijOqT1kA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
