On Thu, Mar 2, 2017 at 9:03 AM, 'Eric Anderson' via grpc.io < [email protected]> wrote:
> On Thu, Mar 2, 2017 at 8:38 AM, Mark D. Roth <[email protected]> wrote: > >> On Thu, Mar 2, 2017 at 8:24 AM, Eric Gribkoff <[email protected]> >> wrote: >> >>> On Thu, Mar 2, 2017 at 8:15 AM, Mark D. Roth <[email protected]> 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. > 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/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. > -- 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/CALUXJ7j%3DbnPCNgNZw5m444r3eaaVYCYSuY%2BwaM95oQhK-xAdvA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
