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
Graylog should natively support http/2 for the web UI.
Graylog has the tendency to make large amounts of small requests to the server. These would be slightly faster from user perspective if http/2 was in use, even without any other changes.
I think the service is run by Jersey which supports http/2. However http, and http/2 capable services seem to be different classes. I have no idea whether the http/2 capable endpoint also can speak http/1. Perhaps adding an experimental configuration option for changing the protocol implementation could be a good approach here.
I investigated serving http/2 to clients but downgrading the protocol at reverse proxy. It's a very bad idea because of the security implications related to downgrades. The whole chain handling requests should natively speak h2/h2c for security reasons.
The text was updated successfully, but these errors were encountered:
Just out of curiosity, are you recommending this as a theoretical optimisation or because you are actually experiencing issues with the way the frontend works right now?
No acute issue. I tested the web UI using http/2 (with the downgrade), and it feels slightly faster in overall. YMMV, because it depends heavily on your users' network connections.
Graylog should natively support http/2 for the web UI.
Graylog has the tendency to make large amounts of small requests to the server. These would be slightly faster from user perspective if http/2 was in use, even without any other changes.
I think the service is run by Jersey which supports http/2. However http, and http/2 capable services seem to be different classes. I have no idea whether the http/2 capable endpoint also can speak http/1. Perhaps adding an experimental configuration option for changing the protocol implementation could be a good approach here.
I investigated serving http/2 to clients but downgrading the protocol at reverse proxy. It's a very bad idea because of the security implications related to downgrades. The whole chain handling requests should natively speak h2/h2c for security reasons.
The text was updated successfully, but these errors were encountered: