Allow zero-length strings in x-correlator header #387
Conversation
rartych
requested review from
PedroDiez,
RubenBG7,
patrice-conil and
shilpa-padgaonkar
as code owners
| | `x-correlator` | Service correlator to make E2E observability | `type: string` `pattern: ^[a-zA-Z0-9-]{0,55}$` | Request / Response | No | Yes | b4333c46-49c0-4f62-80d7-f0ef930f1c46 | | ||
|
|
||
| When the API Consumer includes the "x-correlator" header in the request, the API provider must include it in the response with the same value that was used in the request. Otherwise, it is optional to include the "x-correlator" header in the response with any valid value. Recommendation is to use UUID for values. | ||
| When the API Consumer includes non-empty "x-correlator" header in the request, the API Provider must include it in the response with the same value that was used in the request. Otherwise, it is optional to include the "x-correlator" header in the response with any valid value. Recommendation is to use UUID for values. |
There was a problem hiding this comment.
If a zero-length (null) value is supported, then the expected response should also be agreed and documented. Is it:
- Response will not include an
x-correlatorheader - Response will include an
x-correlatorheader with null value - Response will include an
x-correlatorheader with server-generated value
I believe #366 / #373 are favouring (1) , in which case the documentation here should add 'If an x-correlator request header is provided with zero-length (null) value, it will be ignored and not included in the response.'
There was a problem hiding this comment.
In our system we generate a valid value. Option 3.
We can accept to include both Options 1 and 3
There was a problem hiding this comment.
I've included a hidden recommendation for option (1) stating :
When the API Consumer includes non-empty "x-correlator" header in the request
But I guess it would be clearer to add the proposed sentence:
If an x-correlator request header is provided with zero-length (null) value, it will be ignored and not included in the response.
There was a problem hiding this comment.
Even indicated with empty value we also want to support the option to return a value. Our system returns a server-generated value even not provided by the API client. In case API client provides a value it is keep as it is in the response
There was a problem hiding this comment.
I believe #366 / #373 are favouring (1) , in which case the documentation here should add 'If an x-correlator request header is provided with zero-length (null) value, it will be ignored and not included in the response.'
Implementations should be free to do this for a null value, but it should not be mandated. Implementations have been allowed to always return an x-correlator header whether it is present in the request or not, and we should not change that now, or it may break existing implementations.
So I agree with the current text proposal, which only mandates that the value of x-correlator in the response must be the value in the request only if it is "non-empty". Otherwise the implementation is free to return any valid value, or no x-correlator header at all.
|
Added missing pattern in event-subscription-template.yaml |
4 participants
What type of PR is this?
What this PR does / why we need it:
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 - the pattern was changed to accept zero length of x-correlator string.
Such header should be not returned in the response.
Which issue(s) this PR fixes:
Fixes #383
Does this PR introduce a breaking change?
Special notes for reviewers:
Changelog input
Additional documentation