Use url.PathUnescape rather than url.QueryUnescape in baggage parsing

[n-oden]

I believe this addresses the majority of the cases described in #3601

Golang's url.QueryUnescape will render url path elements (e.g. /, +) as spaces: foo+bar is rendered as foo bar. Path elements are (as I read the spec) legal W3C baggage values, and replacing them with spaces fails the value validation regex.

url.PathEscape allows path elements through unmolested.

[codecov]

Codecov Report

Merging #4667 (59af688) into main (ce7b40a) will decrease coverage by 0.1%.
The diff coverage is 100.0%.

@@           Coverage Diff           @@
##            main   #4667     +/-   ##
=======================================
- Coverage   81.7%   81.7%   -0.1%     
=======================================
  Files        225     225             
  Lines      18056   18056             
=======================================
- Hits       14764   14762      -2     
- Misses      2994    2996      +2     
  Partials     298     298             

Files	Coverage Δ
baggage/baggage.go	98.9% <100.0%> (ø)

... and 1 file with indirect coverage changes

[pellared]

I do not have time review at this moment, but could you please also confront your changes with the following issues which seem to be related?

• baggage module fails to accept baggage produced by itself #4241
• Baggage API is not working, entangled with W3C Propagator #3685
• Baggage is not propagated by OpenTracing bridge #2793

[allan-meng]

Running into the same issue. Do we have an ETA on when this fix will be released?

[Lim3nius]

This doesn't fix problem with #4241 as I have checked here, because problem there is in parseMember after value is unescaped from wire transmission, it is still checked, whether it's value is still compliant with W3C baggage specification (valueRe check), although it doesn't have to be.

In my opinion it would be best to address the bigger problem with baggage, which is demostrated in my example and best solution IMHO is described here

[n-oden]

@pellared those issues are all extremely long and most link to other issues. Respectfully, no: I am not going to trawl through all of the cases described across all of those tickets to determine if this PR applies. This PR fixes a specific bug (handling of + and / characters in baggage values) and adds unit tests to verify that the fix works as described and does not break any of the other tested cases. If that's not considered a useful contribution we are happy to just use our own fork internally until the larger issues are sorted out.

@Lim3nius I agree that the path forward described by @yurishkuro would be the correct long-term plan. But he admits up front that this would be a breaking change and thus presumably fodder for a v2.0 release. I would like to not wait until then to fix this particular bug, which is actively breaking tracing in our organization.

[MikeGoldsmith]

I agree here with @n-oden. This PR helps solve the immediate bug in correctly handling specific characters. The longer-term suggested fix from #3685 is larger, breaking change and hasn't been addressed in 6+ months.

This PR provides a simpler, non-breaking solution that at least makes the root cause a little easier to deal with.

Are there any specific concerns, or questions around this being reviewed?

[pellared]

Are there any specific concerns, or questions around this being reviewed?

None that I am aware of. I will ask during SIG meeting to review it.
@MikeGoldsmith, feel free to review it as well 😉

[MikeGoldsmith]

Other than updating the PR number in the changelog, this looks good to me.

I confirmed this is the same behaviour other SDKs use to encode baggage values.
For example: Java SDK (uses custom parser, but does path escaping)

[pellared]

Initially, I was hesitant to approve this PR as I find it bug-prone and improper to use url.PathUnescape for decoding and url.QueryEscape for encoding.

However, I was playing with different unit test cases on your PR for about an half an hour and it produces better results than the current implementation.

Ideally we should have a dedicated decoding and encoding logic. But I am OK approving it as it is, because perfect is the enemy of good.

Please make sure to update the changelog and keep the PR up to date (or give the maintainers permission to update the branch).

[n-oden]

@pellared @MikeGoldsmith Updated the changelog and brought this up to date with the main branch -- should be good to go, thank you!

[n-oden]

So.... who merges this and what would be the expected ETA to getting it into a full release?

[pellared]

So.... who merges this and what would be the expected ETA to getting it into a full release?

This requires at least a second approval from an approver or maintainer. Please make sure to keep the PR up to date.

Release would be probably in a matter of few weeks, but I cannot promise anything.

[n-oden]

@MikeGoldsmith can I trouble you for a second approval? :)

[pellared]

@open-telemetry/go-approvers PTAL

[n-oden]

n.b. the failing coverage test appears to be an infra issue:

[2023-10-30T13:46:50.133Z] ['error'] There was an error running the uploader: Error uploading to [https://codecov.io:](https://codecov.io/) Error: There was an error fetching the storage URL during POST: 404 - {'detail': ErrorDetail(string='Unable to locate build via Github Actions API. Please upload with the Codecov repository upload token to resolve issue.', code='not_found')}
[2023-10-30T13:46:50.134Z] ['verbose'] The error stack is: Error: Error uploading to [https://codecov.io:](https://codecov.io/) Error: There was an error fetching the storage URL during POST: 404 - {'detail': ErrorDetail(string='Unable to locate build via Github Actions API. Please upload with the Codecov repository upload token to resolve issue.', code='not_found')}
    at main (/snapshot/repo/dist/src/index.js)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
[2023-10-30T13:46:50.134Z] ['verbose'] End of uploader: 1201 milliseconds
Error: Codecov: Failed to properly upload: The process '/home/runner/work/_actions/codecov/codecov-action/v3.1.4/dist/codecov' failed with exit code 255

[robbkidd]

I'm not an OTel Go approver, but I work with @MikeGoldsmith (who is on holiday until next week). He and I reviewed this PR together and I agree with the update for whatever a grey checkmark approval is worth!