Skip to content

[reporting] add known issue about reporting failing in >= 9.0.0 when using config server.protocol: http2 #1991

Open
@pmuellr

Description

@pmuellr

Description

In release 9.0.0, Kibana changed to use the http2 protocol to communicate with Elasticsearch. Before that, it used http1. This user-settable via the server.protocol config, either of those two settings http1 or http2.

There is a problem in reporting when accessing the primary page being accessed, that the headers are sent incorrectly, causing the report generation to fail. This only affects PNG and PDF generation, and not CSV generation. This only occurs when the server.protocol setting is http2.

As the support for http2 was added in 8.15, any versions greater than that would be affected IFF they overrode the default and used a setting of server.protocol: http2.

ESS is not affected, as it specifically enables only http1, for now.

Serverless is not affected, as it doesn't support generating PNG or PDF reports.

All other environments could be affected

  • = 8.15 using server.protocol: http2

  • = 9.0.0 not using server.protocol: http1

The problem can be identified by an ERROR level message logged by Kibana: Failed to complete a request using headers: Protocol error (Fetch.continueRequest): Invalid header.

To work around this till we have a fix in the code released, customers will have to use the setting server.protocol: http1 to generate PNG and PDF reports.

Resources

SDH where we noticed this: https://github.com/elastic/sdh-kibana/issues/5543
Public Kibana issue: elastic/kibana#225915

PR when http2 support was added in v8.15.0 - elastic/kibana#183465
PR when http2 support became the default in 9.0.0 - elastic/kibana#204384

PR with fix in code to allow http2 to be used with reporting - elastic/kibana#225919 (currently in review)

Which documentation set does this change impact?

Elastic On-Prem and Cloud (all)

Feature differences

I added Cloud to the doc set above, because in theory a customer on cloud could be using http2 via overrides (not clear if customers could set this, but operators likely could in any case). Seems unlikely, but ???

Serverless is NOT affected.

Besides that - no difference in the problem in the two envs. We believe this is likely going to affect on-prem customers.

I'm not sure yet what releases this will ship in ...

What release is this request related to?

N/A

Serverless release

serverless is not affected

Collaboration model

The documentation team

Point of contact.

Main contact: @pmuellr @mikecote

Stakeholders: @elastic/response-ops

Metadata

Metadata

Labels

Team:ExperienceIssues owned by the Experience Docs Team

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions