zilla:correlation-id header sort

[dudo]

Is your feature request related to a problem? Please describe.
Currently, correlationId is calculated on the headers as is. I experienced some curl commands mixing up the header order, and getting different ids

Describe the solution you'd like
Sort the headers before calculating the digest.

Describe alternatives you've considered
Not sure if there's a more clever java-y solution that can inspect a hash/dictionary and give the same value regardless of order.

Additional context
I believe the code that calculated the correlationId is here? I'm happy to work on a PR.

[attilakreiner]

@dudo, thx for submitting this issue. I couldn't replicate this behaviour with curl. Can you post some specific reproduction steps, the actual curl commands, that resulted in the mixed-up header order?

[attilakreiner]

After some more deep dive, it turns out that the header order wasn't the problem in the first place.

The problem was caused by the missing idempotency key as the curl command was issued this way:
curl -X POST http://localhost:9090/command -H "idempotencyKey: hello"
as opposed to
curl -X POST http://localhost:9090/command -H "Idempotency-Key: hello"
(Mind the missing dash; the upper/lower case doesn't actually make a difference.)

In the first case, the idempotency key was missing, so zilla generated a random one, that's why the correlationId was a different value on every invocation of the command. In the second case, when using the correct command, the resulting correlationId is consistently the same for multiple invocations of the same command. The ordering of the headers (and other input pieces for the hash) is actually deterministic.

FYI: All header names are converted to lowercase, because we internally follow http2 header naming conventions in our abstractions, even for http/1.1.

For more information pls chk this slack thread:
https://aklivitycommunity.slack.com/archives/C027SEH2KRC/p1697144918651569