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/CA%2B4M1oMCWqsPg8npw0WGuFnPyMNuf1xpQbr1fa%3DR8AMCx0an8w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
