You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, application error code STOPPING(0) is defined, and reserved in transport.
I think that defining and reserving "NOERROR" application code in transport is nice because an implementation can initialize error code variables with it. STOPPING does not sound like "NOERROR" for me. Perhaps, use 0 for NOERROR, and 1 for STOPPING.
The text was updated successfully, but these errors were encountered:
The application is expected to send RST_STREAM with an application error code, except for the one case when the transport sends it in response to a STOP_SENDING. STOPPING is reserved in the application error code space for the transport to use for this one case. It's not really NOERROR.
I understand the initialization problem (which is why 0 tends to be special), but when sending a RST_STREAM from the application, 0 (STOPPING) should not be used. It's only to be used by the transport. The application can initialize to 0 and should not call RST_STREAM with 0. (See the http draft, STOPPING is purely reserved but the semantics are not defined there.)
I see that there's a sentence that needs fixing "A STOP_SENDING frame requests that the receiving application send a RST_STREAM frame." This should have "endpoint" or "transport" instead of "application". That may have caused some confusion -- I'll fix this.
At the moment, application error code STOPPING(0) is defined, and reserved in transport.
I think that defining and reserving "NOERROR" application code in transport is nice because an implementation can initialize error code variables with it. STOPPING does not sound like "NOERROR" for me. Perhaps, use 0 for NOERROR, and 1 for STOPPING.
The text was updated successfully, but these errors were encountered: