Hurl, I've Come to Bargain

Ever since I started the open source journey, I've wanted to contribute to a real Rust project. As much as I adore my own little project . It was recommended by my professor, who also told me that the maintainer of this project (Shout out to you, is a popular command line utility that interacts with various network protocols. Behind curl there's a library for virtually every programming language out there, among which Rust is one of them.

, my eyes landed on from their doc, and the

With even more confusion in mind, I asked the maintainer. He explained that the CURLOPT_TCP_KEEPALIVE option might not be what we were looking for. Instead, he pointed me to .

Later I learned that, the --no-keepalive flag in curl, as well as the libcurl option, only controls whether or not the client sends TCP keepalive probes to keep the connection alive. It does not dictate how the client reuses these connections.

I verified this using my trusty networking tool . I carefully examined their PR history and found

One more thing I really love about this project is that they have included . One involved a workaround in another part of the code, and the other was about docs. I submitted my fix thinking this was ready to merge.

However, later the maintainer . It was similar but also different. Once again, the maintainer patiently explained their expectations:

• Implement the -H/--header cli option, as well as in the [Option] field inside the hurl file.


• The cli flag is an existing curl option. It adds additional headers to each request.


• In the future, they will implement a global [Option] field in the hurl file, which this option should also support.


• There should be two PRs on this issue:
  
  
  
  
  • The first PR implements the cli option.
  
  
  • The second PR supports the hurl file.
  
  
  
  
  
  

Perfect! Sounds like a big challenge but not something completely unachievable. This time, however, was not as smooth sailing as I had hoped.

To make sure my code behave the same way as curl, I first looked into their , it handles options from both cli arguments and the hurl file. And here's where I made my first mistake:

I saw the code to apply headers and directed all my attention to it without properly understanding how the hurl file options are processed. I invested in a lot of time and energy to implement the override behavior, and had to use workarounds due to , I was greeted with a full essay of proposed changes. In the request, the maintainer further explained the wanted behavior, and suggested that I implement some code to aggregate the user specified headers before passing to the handler. He also proposed that I split this PR into two parts: One part implements the aggregation (with unit tests), another part implements the actual cli option.

It was humbling to see feedback as such, but I was also genuinely moved by the thoughts and efforts the maintainer had put into it. It was reassuring and somehow made me feel better about my work going forward.

Attempt #...?

I started with one simple issue and ended up with a totally different issue and 3 requested PRs. Who knows how many more attempts I will have to make?

Despite all that, I'm fully committed (no pun intended) to it! It has been an incredible opportunity to not only learn about Rust, curl, HTTP, but also working with people to solve uncertain problems in a moving project. I'm excited to see how this goes and certainly not gonna stop right here.