[ZBX-21765] incorrect format for custom HTTP header causes web scenario failure (Wont'f Fix, see comments) Created: 2022 Oct 14  Updated: 2024 Apr 10  Resolved: 2022 Nov 29

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: 6.0.9, 6.2.2
Fix Version/s: 6.0.11rc1, 6.2.5rc1, 6.4.0beta4, 6.4 (plan)

Type: Problem report Priority: Major
Reporter: Oleksii Zagorskyi Assignee: dimir
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Causes
causes ZBX-22001 Web scenario step fails to find patte... Closed
Duplicate
Team: Team A
Sprint: Sprint 93 (Oct 2022), Sprint 94 (Nov 2022)
Story Points: 0.7

 Description   

Ok, the story started from this:
there in a web application which did not like the fact that by default zabbix sets CURLOPT_ACCEPT_ENCODING option
https://curl.se/libcurl/c/CURLOPT_ACCEPT_ENCODING.html
which resulted this header automatically included to each HTTP request:

Accept-Encoding: deflate, gzip, br

and the web application responded with this:

HTTP/1.0 400 Bad Request
Content-Length: 89
Content-Type: text/html

<html><head><title>Bad Request</title></head><body><h1>400 Bad Request</h1></body></html>

It was not easy to understand where is the issue because "curl" tool in shell does not set the header.
Everyone is using curl for testing, right? So, small question here is - why do we set the header in zabbix? ... well ...

By manual tests using curl in shell I figured out that the app does not like "br" entry in the list.
In the same time the app did not complain on values like "foo" or "bar" or "foo, bar" - which is funny.
I don't know what is libcurl version installed on the system, but on my recent Ubuntu with libcurl 7.81.0 it sets the header with a bit longer list:

Accept-Encoding: deflate, gzip, br, zstd

Not sure how that is precise, but according to information I have the web app is working on Apache/2.4.6.

To workaround the issue, on the scenario level I've added a custom header "Accept-Encoding" with value "*", which was tested and supposed to work. But .... it did not work in zabbix. The web app complained with the same error.
And reason for that was a missing space character after colon, generated header was:

Accept-Encoding:*

Luckily it was possible add a trailing space in front of "*" and save that in frontend.
Generated header became this:

Accept-Encoding: *

and monitoring started to work.

I've tried to reproduce that issue with missing space in custom header on my Apache/2.4.52 (as monitored web app) and I could not - it did not complain.

I've tried to find some standard about HTTP proto, and looks like this is most relevant link:
https://datatracker.ietf.org/doc/html/rfc2616#section-4.2
but it does not mention the space for formatting.

But having this real case and that fact that all other headers are using the space character, I'm sure we also have to add a space in our custom headers.

 Comments   
Comment by Oleksii Zagorskyi [ 2022 Oct 14 ]

Just a note that it should be possible to unset a header after this recent fix - ZBX-19224

Comment by dimir [ 2022 Oct 19 ]

First, a quote from cURL docs on why there were deflate, gzip, br" and then deflate, gzip, br, zstd":

To aid applications not having to bother about what specific algorithms this particular libcurl build supports, libcurl allows a zero-length string to be set ("") to ask for an Accept-Encoding: header to be used that contains all built-in supported encodings.

Alternatively, you can specify exactly the encoding or list of encodings you want in the response. The following encodings are supported: identity, meaning non-compressed, deflate which requests the server to compress its response using the zlib algorithm, gzip which requests the gzip algorithm, (since curl 7.57.0) br which is brotli and (since curl 7.72.0) zstd which is zstd. Provide them in the string as a comma-separated list of accepted encodings, like: "br, gzip, deflate".

This is what Zabbix does, it sets the "Accept-Encoding" to empty string ("") and this libcurl then fills it with everything it knows about. Zabbix does that in all the places where it performs HTTP request using libcurl, including:

  • HTTP agent item
  • VMWare checks
  • Scheduled reports
  • Web monitoring
  • net.tcp.service with https
  • web.page.*
  • Elastic history
  • Email media type with authentication
  • Hashicorp
  • Cyberark
  • Script item
  • Webhook media type

The question is should we skip setting this header in all the places or only Web Monitoring. I propose the latter.

Comment by dimir [ 2022 Oct 19 ]

Fixed in development branch feature/ZBX-21765

Before the fix by default Zabbix server was sending the following HTTP headers in a web scenario step request:

Host: 192.168.7.48:100
User-Agent: Zabbix
Accept: */*
Accept-Encoding: deflate, gzip, br

After the fix:

Host: 192.168.7.48:100
User-Agent: Zabbix
Accept: */*
Comment by dimir [ 2022 Nov 09 ]

Fixed in:

Comment by Oleksii Zagorskyi [ 2022 Nov 09 ]

How about adding the space character  to split "key: value" pair in custom headers ?

Comment by dimir [ 2022 Nov 29 ]

Let's fix that in a separate ticket, will be easier to process it.

ZBX-21999

Comment by dimir [ 2022 Dec 01 ]

Caused ZBX-22001

Comment by dimir [ 2022 Dec 02 ]

Unfortunately this change should be reverted. It disables support for response decompression by Zabbix completely (even though cURL library might be able to do it). This is not fair for those users that use web monitoring with content compression.

There is no way to enable decompression support using just headers. A specific directive to cURL library must be used in this case, which was removed by this change.

Before this change

Zabbix server was generating a request with header

Accept-Encoding: deflate, gzip, br

which enables response decompression for the mentioned algorithms. When response was compressed using one of those Zabbix server was able to decompress it.

After this change

Zabbix server is generating a request without "Accept-Encoding" header and disables the ability to decompress the response completely.

Decision

We have to revert those changes in ZBX-22001 and if the control over "Accept-Encoding" value is needed it must be addressed in separate feature request. As a workaround, as suggested by zalex_ua, add

Accept-Encoding: *

to the web scenario or a web scenario step where it's needed.

Generated at Tue May 13 09:40:04 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.