FYI: It's still needed to create some test coverage related to other methods and probably fix the existing ones (unfortunately I'm having a bad time testing on Manjaro). With that, said there's still work to be done.

Hello, @255kb! I was thinking to add a new context menu when it's a proxied request to the user be able to copy either the Mockoon request or the proxied request made by Mockoon. What are your thoughts on that?

I'd also like to hear your concerns about changing the http utils with the default value as {}. In my perspective I could remove this default {} to have more reliability of unit tests, assuring the body is sent only when requested. Context: https://github.com/mockoon/mockoon/blob/main/packages/desktop/test/libs/http.ts#L102
I found this behavior when I was creating the unit tests for this PR. If you do want to keep it as it is, I'll try to workaround to make sure some tests cover when the body is not sent.

Hello, @255kb! I was thinking to add a new context menu when it's a proxied request to the user be able to copy either the Mockoon request or the proxied request made by Mockoon. What are your thoughts on that?

Could you provide an example of the difference between the two? I guess it would be the URL? My first reaction: is it really useful to copy a CURL command that is not pointing to the Mockoon instance?

I'd also like to hear your concerns about changing the http utils with the default value as {}. In my perspective I could remove this default {} to have more reliability of unit tests, assuring the body is sent only when requested. Context: https://github.com/mockoon/mockoon/blob/main/packages/desktop/test/libs/http.ts#L102 I found this behavior when I was creating the unit tests for this PR. If you do want to keep it as it is, I'll try to workaround to make sure some tests cover when the body is not sent.

Feel free to improve this util. It is quite old! Just make sure that it's still working for all the other tests (obviously ;) ).

@Mavbraz tried it, works well. One suggestion:

We should add --compressed as default when we copy for convenience if there's a header --header 'accept-encoding: gzip, deflate' in the request that's copied. We could make a setting option for this?

@regalstreak that's a good suggestion, but there're many compression types not mentioned. e.g: br and zstd.
IMO we should add the --compression if we have the accept-encoding header not blank.

I agree it should have a setting to configure its use and IMO it should be true by default.

What are your thoughts on that matter?

@regalstreak @Mavbraz Do we really need a setting for that? My understanding was that curl's --compressed flag would work or not but only fail if the server use an unsupported compression method.
I would say we could always include the flag. But I'm also not a curl specialist :)

@Mavbraz PR seems kind of ready. Do you think we can finalize it in the coming week or two to include it in v9.3.0?

@Mavbraz Do you think you could finalize by adding the --compress flag? Then we could move on with the review and hopefully finalize for v9.4.0 due soon.

@255kb, I think this could be a good setting, at least in my case. Sometimes I need to copy the request and the allowed compression algorithms exactly.
That said, I’ll enable this compression flag by default.

I'll rebase this branch and push all my changes soon. Probably, it'll be possible to move with the review soon and make it to next release.

@255kb, I think this could be a good setting, at least in my case. Sometimes I need to copy the request and the allowed compression algorithms exactly. That said, I’ll enable this compression flag by default.

Thank you for updating the PR!

I still don't see why we would need a setting. The curl command should replicate the request, if it had an accept encoding header it should include the compression flag, if not it shouldn't. Isn't it too complicated to change the setting instead of just removing the compression flag from the copied command if needed?

It was rethinking about this setting and indeed it was not much valuable as I though.
Probably, I wouldn't use that much and if I need some day I'll just change it manually.

Thanks for the update!
Is it ready for review? I plan to do the release early next week.

Btw, I ran the CI and some tests are not passing.

This latest commit I updated some models to get the original headers sent, I also fixed the failing tests and refactored the command logic to use a builder as it would give much better readability and maintainability.

That said, I think now it's good to go with the reviewing, but there are just a few points I would like to discuss first:

1. I used the --data-binary since it reproduce the same amount of bytes as the user sent and that's useful if you also use Mockoon as proxy as I do. With that, it's easier to reproduce some bug or something else. What are your thoughts on that? I'd like to keep that to help out many people who uses Mockoon as a Mock and Proxy at the same time
2. The command may generate breaking lines due to the body content as a result of the point I said above, but I do not generate any command breaking line for terminals since it differ on OSes (Mac/Linux and Windows) and terminals (Terminal, powershell, cmd, etc). I couldn't find a good solution to work with all that and it'd give many maintainability problems in the future. Then it'd the users responsability of doing that. Very similar as the default postman behavior. Do you agree or have any better idea?

This latest commit I updated some models to get the original headers sent, I also fixed the failing tests and refactored the command logic to use a builder as it would give much better readability and maintainability.

That said, I think now it's good to go with the reviewing, but there are just a few points I would like to discuss first:

1. I used the --data-binary since it reproduce the same amount of bytes as the user sent and that's useful if you also use Mockoon as proxy as I do. With that, it's easier to reproduce some bug or something else. What are your thoughts on that? I'd like to keep that to help out many people who uses Mockoon as a Mock and Proxy at the same time
2. The command may generate breaking lines due to the body content as a result of the point I said above, but I do not generate any command breaking line for terminals since it differ on OSes (Mac/Linux and Windows) and terminals (Terminal, powershell, cmd, etc). I couldn't find a good solution to work with all that and it'd give many maintainability problems in the future. Then it'd the users responsability of doing that. Very similar as the default postman behavior. Do you agree or have any better idea?

Thanks for the update. I wrote some comments as part of the review.

Regarding 1, sounds good.
Regarding 2, I agree, let's keep it like that for now. Also, we don't have access to the rawBody where the logs are created.

When testing I noticed that the curl command will always use localhost, even though we can now have cloud logs originating from a xxxx.mockoon.app instance. I will merge on an intermediary branch and fix this as you don't have an easy way to test that right now.

Update: Don't investigate the failing Windows test, it must be flaky as it's passing locally and on Linux.

Is this PR going to be merged with squash commit? If not, I can do it to prevent make the main a mess.

Is this PR going to be merged with squash commit? If not, I can do it to prevent make the main a mess.

Yes commits will be squashed.

Thanks for the review! I fixed the failing tests.

Although, I found an edge case of copy as curl for WebSocket. The copy as curl is enable for it and the curl command is functional when used by terminal, but it doesn't work on Postman.
I'm wondering if that's good or not to be enabled for the WebSocket command... I don't see problems to keep that, but it may confuse some people since it doesn't work on Postman.

Thanks for the review! I fixed the failing tests.

Thanks! I will merge and implement the Cloud logic.

Although, I found an edge case of copy as curl for WebSocket. The copy as curl is enable for it and the curl command is functional when used by terminal, but it doesn't work on Postman. I'm wondering if that's good or not to be enabled for the WebSocket command... I don't see problems to keep that, but it may confuse some people since it doesn't work on Postman.

If it's working with curl it's ok. We don't have to accomodate for each and every tool out there.