On Mon, Feb 27, 2017 at 8:53 AM, 'Mark D. Roth' via grpc.io < grpc-io@googlegroups.com> wrote:
> While talking with Craig on Friday, we realized that we need to make the > wire protocol a bit stricter in order to implement retries. > > Currently, the spec allows status to be sent either as part of initial > metadata or trailing metadata. > Currently the spec doesn't say when it is appropriate. This is because the spec is only on the HTTP/2 level and doesn't actually define gRPC semantics. I think you mean HTTP headers and trailers instead of using the term "metadata." gRPC always has trailing metadata, but may not have initial metadata. Status must come on the trailing metadata. In HTTP parlance, it may come in the initial headers only when those initial headers are the end of the response. However, as per the When Retries are Valid > <https://github.com/ncteisen/proposal/blob/75e08fa10405430e8177cfd91bf63a25ff4ad617/A6.md#when-retries-are-valid> > section > of the gRFC, an RFC becomes committed when "the client receives a non-error > response (either an explicit OK status or any response message) from the > server". > Just to be clear, the only time "an explicit OK status" would matter is with a streaming call. In a unary call the OK status will always be after the response message. > This means that in a case where the server sends a retryable status, if > the status is not included in the initial metadata, the client will > consider the RPC committed as soon as it receives the initial metadata, > even if the only thing sent after that is the trailing metadata that > includes the status. > What? That does not seem to be a proper understanding of the text, or the text is wrongly worded. Why would the RPC be "committed as soon as it receives the initial metadata"? That isn't in the text... In your example it seems it would be committed at "the trailing metadata that includes a status" as long as that status was OK, as per the "an explicit OK status" in the text. Thus, we need to require that whenever the server sends status without > sending any messages, the server should include the status in the initial > metadata (and then close the stream without bothering to send trailing > metadata) instead of sending both initial metadata and then trailing > metadata. > This is generally good practice assuming you mean "headers" instead of "metadata". But I don't see any argument here for requiring it and I don't see any impact to retry. Since an application can force initial headers to be sent (at least in Java), this can't really be a strong requirement. Java does do this generally though, as was required for our Auth support and similar conversion of gRPC status codes to HTTP status codes. Based on a previously encounted interop problem (see https://github.com/ > markdroth/grpc/pull/3, which was included in https://github.com/grpc/ > grpc/pull/7201), I believe that grpc-go already does the right thing here > (although Saila and Menghan should confirm that). However, since that > previously encountered problem did not show up with Java or C++, I suspect > that those stacks do not do the right thing here. > If my correction of the nomenclature is correct, then Java already does this for the most part. This isn't something that can be enforced in Java. But the normal stub delays sending the initial metadata until the first response message <https://github.com/grpc/grpc-java/blob/master/stub/src/main/java/io/grpc/stub/ServerCalls.java#L281>. If the call is completed without any message, then only trailing metadata is sent. -- 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%2B4M1oM3EeiLrbDUCkpafUZV7%3DBXN6KRp%3DJ6z8Q-OtYqCmpKCQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
