feat: avoid clobbering original body for next read

[StevenACoffman]

Hello! If you read the request body the way you do, subsequent layers (like a logging middleware) will find it empty. This copy's the original body and reads that, preserving the original for subsequent reads.

Signed-off-by: Steve Coffman [email protected]

[ioito]

/close #48

[djale1k]

Regarding the issue #48 If we call this in a long process and more req at time the performance boost I made it's good maybe in this case it's better to keep your copy of req before sending it to GetCurlCommand @moul @StevenACoffman @ioito

[StevenACoffman]

@Dzalevski Presumably people are making HTTP Requests to do something useful, and this library is used for logging or debugging, so #31 broke existing usages of this library, which I discovered when I updated.

If both safely reading the request and better-performing-but-unsafely reading the request use cases were desirable, there could be an additional function, but the documentation should warn people using the unsafe one.

So this would have GetCurlCommand and GetCurlCommandUnsafe or GetCurlCommandNoClobber

[github-actions]

🎉 This PR is included in version 2.3.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[dominik-lekse]

To clarify: This PR and therefore release 2.3.0 restores the behavior of GetCurlCommand before the merge of PR #31?

I agree with the argument of @StevenACoffman, that #31 introduced a breaking change by emptying the request body. To provide an insight on a use case, I am using http2curl to log HTTP requests as part of an integration test suite. After the upgrade with the breaking change, I spent an unreasonable amount of time to investigate why the service under test did not receive any request body.

Therefore, :thumbs: up for the proposal by @StevenACoffman to add the performance-optimized version as a new function. I throw GetCurlCommandFast in the arena of possible names.