On Thu, Mar 2, 2017 at 9:13 AM, Eric Gribkoff <ericgribk...@google.com> wrote:
> > > On Thu, Mar 2, 2017 at 9:03 AM, 'Eric Anderson' via grpc.io < > grpc-io@googlegroups.com> wrote: > >> On Thu, Mar 2, 2017 at 8:38 AM, Mark D. Roth <r...@google.com> wrote: >> >>> On Thu, Mar 2, 2017 at 8:24 AM, Eric Gribkoff <ericgribk...@google.com> >>> wrote: >>> >>>> On Thu, Mar 2, 2017 at 8:15 AM, Mark D. Roth <r...@google.com> wrote: >>>>> >>>>> I agree that we don't need to say anything about whether or not the >>>>> server delays sending Response-Headers until a message is sent. However, >>>>> I >>>>> think we should say that if the server is going to immediately signal >>>>> failure without sending any messages, it should send Trailers-Only instead >>>>> of Response-Headers followed by Trailers. >>>>> >>>>> >>>> >>>> This is in the retry gRFC doc now (https://github.com/ncteisen/p >>>> roposal/blob/ad060be281c45c262e71a56e5777d26616dad69f/A6.md# >>>> when-retries-are-valid). >>>> >>> >> The language is still confusing: >> >>> The client receives a non-error response from the server. Because of the >>> gRPC wire specification, this will always be a Response-Headers frame >>> containing the initial metadata. >> >> >> What does "non-error response" mean there? I would have expected that >> means receiving a Status in some way (which is part of Response), as >> otherwise how is "error" decided. But the next part shows that isn't the >> case since Status isn't in Response-Headers. >> >> > The second sentence is defining what non-error response means: a > Response-Headers frame. The only alternative (an "error" response) is > Trailers-Only. I can chose a name other than "non-error response" to make > this clear. > It would probably be simpler to simply say "The RPC is committed when the client receives Response-Headers." > > >> 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/ms >> gid/grpc-io/CA%2B4M1oON-6sgSW%3DLLJZLABLm_RFCFgNb%2Bki6% >> 2BbwJuxMMPXMxUA%40mail.gmail.com >> <https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oON-6sgSW%3DLLJZLABLm_RFCFgNb%2Bki6%2BbwJuxMMPXMxUA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- Mark D. Roth <r...@google.com> Software Engineer Google, Inc. -- 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/CAJgPXp573SKiKu_NBCsz-AVAX-CDwioqEapyBOnq19Ht_%3DgMQA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
