x-correlator with no value (empty / null)

[ToshiWakayama-KDDI]

Dear CAMARA Commonalities specialists,

When the API Consumer includes the "x-correlator" header in the request, if it does not have any value (empty, null or something like that), how the API Provider should handle it? It is appropriate to regard a no-value x-correlator as no x-correlator header existing?

Many thanks,
Toshi

[Kevsy]

Hi @Toshi -

HTTP applies the same syntax rule for all header field content, and this allows empty header fields, although only the definitions of Allow and Accept-Encoding document the semantic of an empty field content.

This means that sending an empty HTTP header is not "breaking HTTP", and because of that I suspect common HTTP libraries will not throw an exception if an empty header field is sent.

So to your question:

It is appropriate to regard a no-value x-correlator as no x-correlator header existing?

I think 'yes', and I don't believe the server should include x-correlator in the response when an empty x-correlator has been received..

[sachinvodafone]

Hi @ToshiWakayama-KDDI ,

I believe it ultimately depends on how the provider ensures proper traceability. If the x-correlator header is missing or empty, we can simply generate a new traceable ID on our side to keep everything traceable. This ID helps us with logging and troubleshooting. Before sending the response back, we can map this generated ID in the x-correlator header so the consumer can use it for their tracking as well.

[patrice-conil]

Hi @ToshiWakayama-KDDI,

On our side (Orange) we ignore x-correlator if it's empty and do not re-inject any value.
In all cases for internal tracing we use open-telemetry with standard headers (traceId / span-id or parent-id as defined in W3C Trace Context).

[rartych]

Changes introduced in this PR #373 should eliminate empty x-correlator (it can be discarded as not following the pattern)

[hdamker]

As discussed yesterday within the TSC I see a challenge with the introduction of the pattern in #373.

API Clients which have added the the x-correlator header (as it is listed in the API definitions) but intentionally or unintentionally left it empty or set it to an empty string ("") might break due to this change:

• before the introduction of the pattern these requests were valid and could be treated as if the header was not present
• with the introduction of the pattern these requests will (most?) probably rejected, at least the ones who have set it to an empty string

My view is that API Provider should be liberal and accept NULL (no value) or empty strings within the x-correlator and treat them as if the header was not present. Within the x-correlator pattern we need to accept also strings with zero-lengths for that.