Add --unix-socket option

[ztittle]

This is a feature provided by cURL that allows sending requests to a web server via a Unix Domain Socket. Some use cases include:

• Querying docker API
• Running a web server w/o opening a TCP port for security and/or performance reasons

https://curl.se/docs/manpage.html#--unix-socket

[jcamiel]

Hi @ztittle thank you for this huge PR, this might have been quite difficult to see all the "small" things to cover everything!
I've made some comments on the PR to help to make all the CI checks green:

1. clippy stuff should be fixed with my comments (you can test it locally by running cargo clippy)
2. Black stuff is the linting on Python files. You can run black in your workspace and that should be OK
3. Coverage stuff will be fixed with my comments (you should make a pattern file to avoid libcurl message, see comments)
4. Crates stuff should be fixed if you rebase your PR

Don't hesitate to ask questions, even basic ones, if you need any help.

As you've done a tremendous work as a first contributor with this PR, don't hesitate also to give us feedbacks on what we can improve to make people read/understand the code. This can be anything from better documentation (like README.md on CONTRIBUTING.md), how to run tests, code sample, code comments etc...

[ztittle]

Hi @ztittle thank you for this huge PR, this might have been quite difficult to see all the "small" things to cover everything! I've made some comments on the PR to help to make all the CI checks green:

1. clippy stuff should be fixed with my comments (you can test it locally by running cargo clippy)
2. Black stuff is the linting on Python files. You can run black in your workspace and that should be OK
3. Coverage stuff will be fixed with my comments (you should make a pattern file to avoid libcurl message, see comments)
4. Crates stuff should be fixed if you rebase your PR

Don't hesitate to ask questions, even basic ones, if you need any help.

As you've done a tremendous work as a first contributor with this PR, don't hesitate also to give us feedbacks on what we can improve to make people read/understand the code. This can be anything from better documentation (like README.md on CONTRIBUTING.md), how to run tests, code sample, code comments etc...

Thanks for the quick and very useful feedback!

One thing that took me a little bit of time to grok was understanding how the integration tests were setup, such as the python flask modules. But overall, it wasn't too bad and I liked how it's structured. Something that could be useful for future contributors would be a single script that can be ran that would automate code cleanup/linting, starting the test server, and running the integration tests (with the expected console column width :)) before a pr is created.

[jcamiel]

Hi, thanks for the feedbacks, appreciated.

The least we can do is to improve the docs, I've noted this.

There are still two failed checks:

1. first one is simple. We've reorganized the integration tests so it's not explicit yet. We insure to have 100% coverage for hurlfmt. You just have to take a Hurl file with an [Options] section and with a unix-socket option, export it to HTML and JSON with hurlfmt, and commit it to integration/hurlfmt/tests_ok. That should be OK for the coverage

2. Second one is one windows. In the logs hurl --version shows that libcurl support unix socket so it's not about not supporting unix socket (we could revert the ps1 script btw). Maybe the Unix socket path should use \ instead of / on Windows? I will check the next week with @lepapareil if we can see why it's failing on Windows

[ztittle]

Hi, thanks for the feedbacks, appreciated.

The least we can do is to improve the docs, I've noted this.

There are still two failed checks:

1. first one is simple. We've reorganized the integration tests so it's not explicit yet. We insure to have 100% coverage for hurlfmt. You just have to take a Hurl file with an [Options] section and with a unix-socket option, export it to HTML and JSON with hurlfmt, and commit it to integration/hurlfmt/tests_ok. That should be OK for the coverage
2. Second one is one windows. In the logs hurl --version shows that libcurl support unix socket so it's not about not supporting unix socket (we could revert the ps1 script btw). Maybe the Unix socket path should use \ instead of / on Windows? I will check the next week with @lepapareil if we can see why it's failing on Windows

1. Makes sense. Will do.
2. I looked into the failing windows test a bit more and it's not going to work with the python test server. There is an open issue (Enable AF_UNIX support in Windows python/cpython#77589) about supporting AF_UNIX for Windows, but it is blocked on a technicality on how Unix Domain Sockets is implemented in Windows (missing DGRAM support). It might be possible to create a unix domain socket in windows in rust (I found this crate https://crates.io/crates/uds_windows) for testing purposes, but it might be best to remove the windows integration tests for now.

[jcamiel]

Yep, we can do this for the moment: in the ps1 file returns 255 unconditionally with your comment about why we're skipping it for the moment should be perfect

[jcamiel]

/accept

[hurl-bot]

🕗 /accept is running, please wait for completion.

[hurl-bot]

✅ Pull request merged and closed by jcamiel with fast forward merge..

# List of commits merged from ztittle/hurl/add-unix-socket-option branch into Orange-OpenSource/hurl/master branch:

• 98b0f50 Add --unix-socket option

[jcamiel]

PR is now merged, thanks for your work @ztittle!