-
-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exposing HTTP2 "additional debug data" in received GOAWAY frames #308
Comments
The third value in the goaway tuple, the error code, would also be great to have access to. This is already translated in |
If the error code is not no_error (equivalent to "normal") it probably should be reflected yes. |
+1 for this requirement. |
The close reason just has to be propagated from gun_http2 to gun. Currently gun_http2 returns the There is additional difficulty because:
The last item has the caveat that servers may not send the extra data multiple times, but we'll cross that bridge when we get to it. For now we should just leave a comment in the code indicating that because we keep the last GOAWAY information only, that data may be lost if the server changes what it sends in subsequent GOAWAY frames. |
Being able to act on the "additional debug data" that can be part of the GOAWAY frames is necessary for correct usage of certain services.
One such service is Apple Push Notification service (APNs). When connecting to APNs, if the client certificate is bad or for the wrong environment (prod vs sandbox), the service will send a GOAWAY frame with some JSON stating the error reason, and then close the socket immediately after. In both of these cases, it is meaningless to attempt connecting again as the situation is unlikely to resolve itself and needs intervention.
In the APNs documentation, it is stated "The JSON data might also be included in a GOAWAY frame when a connection is terminated."
When this happens, gun sends a
gun_down
message withreason=normal
:{gun_down,<0.1386.0>,http2,normal,[]}
In the conversation in #cowboy on the Erlang Slack on the 5th of December, Loïc wrote:
The text was updated successfully, but these errors were encountered: