Conversation

Notices

1. Embed this notice
   Ænðr E. Feldstraw (aeveltstra@mastodon.social)'s status on Friday, 10-Mar-2023 06:52:33 JST Ænðr E. Feldstraw

   Today I was reminded that HTTP/2 servers can deny communication quite unceremoniously by sending back a #GOAWAY signal. What do you do to resume communication? Simply retry the request? Or also refresh the #HTTP client that makes the requests?

   • Embed this notice
     Ænðr E. Feldstraw (aeveltstra@mastodon.social)'s status on Friday, 10-Mar-2023 06:52:33 JST Ænðr E. Feldstraw

     in reply to

     #NGINX and other #HTTP servers will throw a fit if a client sends 1000 requests, and literally tell the client to go away. In the #java programming language, the #HttpClient built into the #jdk throws an IOException, without any further specialization. The #Jetty client for HTTP/2 does throw a specific error and also indicates the lost frame ID, for easy resumes. I guess we could switch clients, or I could find a nice way to catch this error and resume communications. Any suggestions?

   • Embed this notice
     feld (feld@bikeshed.party)'s status on Friday, 10-Mar-2023 06:52:33 JST feld

     in reply to
     > and literally tell the client to go away
     
     How? Nginx doesn't return a 429 by default. There is no default policy for that.
   • Embed this notice
     Ænðr E. Feldstraw (aeveltstra@mastodon.social)'s status on Friday, 10-Mar-2023 07:20:10 JST Ænðr E. Feldstraw

     in reply to

     • feld

     @feld I will take your word for that. But we experience GOAWAY signals after 1000 requests, and we are not the only one, according to StackOverflow.com. We didn't implement the server, so we can't vouch for how or why it does anything.

   • Embed this notice
     feld (feld@bikeshed.party)'s status on Saturday, 11-Mar-2023 05:03:02 JST feld

     in reply to
     Thinking about this again --
     
     > can't tell how much of the GOAWAY is signaled by them or by the destination server.
     
     If CloudFlare is in the middle as a proxy it's handling both ends as completely separate HTTP2 sessions. I do not think a GOAWAY from the origin will be passed through to the client. An origin GOAWAY would be received by the reverse proxy at CloudFlare and then it would restart the HTTP2 session and resume sending requests it has queued/buffered
     
     *i think*...
   • Embed this notice
     Ænðr E. Feldstraw (aeveltstra@mastodon.social)'s status on Saturday, 11-Mar-2023 05:03:03 JST Ænðr E. Feldstraw

     in reply to

     • feld

     @feld That server may or may not be hosted by #cloudflare ... And we can't tell how much of the GOAWAY is signaled by them or by the destination server.