Fix returning value for empty header and make possible to differentiate between missing header and empty header

[prembhaskal]

The method get_http_request_headers_bytes return empty vector for empty header value but get_http_request_header_bytes returns None for empty header value.

Similarly get_http_request_headers returns empty String but get_http_request_header returns None.

This commit intends to fix this inconsistency.

With this, it will be possible to differentiate between two cases, a missing header and a header with empty value.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[PiotrSikora]

Which host returns NULL value here?

This code is a legacy code path for "header not found" from Proxy-Wasm ABI v0.1.0, and I'd expect that hosts would return a valid pointer to a zero-sized string, although I guess returning NULL here is also fine.

Also, you need to make the same change in get_map_value_bytes.

(Please ignore the CI failures, they'll get fixed once #306 is merged)

[prembhaskal]

@PiotrSikora I was working with envoy 1.31. I think i got same result with latest envoy(1.33), but I will confirm that.

Also, you need to make the same change in get_map_value_bytes

Actually I made change in that method itself.

[prembhaskal]

@PiotrSikora I think pub fn get_map_value is the legacy one, which returns utf8 string value. I have not changed that, but please let me know if I should.

[PiotrSikora]

@PiotrSikora I think pub fn get_map_value is the legacy one, which returns utf8 string value. I have not changed that, but please let me know if I should.

Oops, sorry! Yes, I've meant that the same change should be made in both get_map_value and get_map_value_bytes, otherwise we're adding pretty weird inconsistency within the SDK.

Also, get_map_value isn't really legacy, since get_map_value_bytes only moves the UTF-8 / HTTP encoding issue out of the SDK and into each plugin. The proper solution is in #287, once that's reviewed and merged.

[prembhaskal]

@PiotrSikora I have updated the method get_map_value now.