This is the end of Sprint 2. This Sprint has gotten me into a lot of joy and pain, and let me tell you all about it.
🪄 Hurl
Support ip query for getting resolved response IP
#3106
A proposal to add an ip query
GET https://foo.com
HTTP 200
[Asserts]
ip == "192.168.0.1"
GET https://foo.com
HTTP 200
[Asserts]
ip matches /2001:0000:130F:0000:0000:09C0:876A:\d*/
In libcurl the corresponding call is CURLINFO_PRIMARY_IP.
There is also a CURLINFO_LOCAL_IP but I've the impression that user expectation is more on primary ip.
Question: what's about port ? Does the query ip exctract the IP address and the port (192.168.0.01:8080), or do we have a separate port query that we can do latter?
GET https://foo.com
HTTP 200
[Asserts]
ip == "192.168.0.1"
port == 8080
With ip/portas separated queries, we can also have isIPv6 and isIPv4 predicates:
GET https://foo.com
HTTP 200
[Asserts]
ip isIPv6
Idea from @lepapareil 😎
This week I've been working to implement this feature to enable hurl users to assert on IP addresses for each request. Since there were quite a few things to do, I decided to break it into multiple PRs.
Add ip address to http::Response (Link)
This was a continuation from last week's research. To make the asserts work, first I had to capture that from libcurl and include it in Hurl's Response module.
To achieve that, I used the method primary_ip provided by the curl crate. There was some issues regarding the return type of this method and the implementation of type conversions, but we worked it out during the previous Sprint.
Other than that, nothing much happened in this PR. There was some changes regarding names and documentation, but it was merged quickly after.
Allow assert on ip address (Link)
After last week's discussion, we decided to simply use the string type to handle ip address queries in the Hurl file. At that point I didn't really understand much of the code, but I was able to find a similar query option : url. Imitating the code, I was able to create a new query entry.
For example:
fn url_query(reader: &mut Reader) -> ParseResult<QueryValue> {
try_literal("url", reader)?;
Ok(QueryValue::Url)
}
became:
fn ip_query(reader: &mut Reader) -> ParseResult<QueryValue> {
try_literal("ip", reader)?;
Ok(QueryValue::Ip)
}
To my surprise, when I tested it afterwards, everything worked! ==, matches or contains... All the keywords was properly working. Turned out Hurl already had the code to handle all string typed queries generically, so all I had to do was creating the query and plugging it right in. Super cool!
Allow asserts on ip versions (Link)
This was technically a different feature but it was still a part of the original issue. In this PR, instead of treating the IP address as a string and query on the text content, I had to figure out way to evaluate the IP version.
The maintainer suggested to simply take the IP query strings and convert them to std::net::IpAddr. Since this is an enum built-in with the V4 and V6 variants, if the conversion succeeds, I could match the pattern to get the IP version.
However, this task was not nearly as straightforward as the last PR. Since I didn't fully understand the code, I had a very difficult time locating where I even implement this conversion.
First I was determined to figure this out myself. I sat down and carefully read the code, I drafted a few diagrams to help me understand the workflow. However, in Hurl's file parser, whenever I tried to print something, or use the debugger to display something, I would get a strange-looking structure instead of actual text like so:
I was beyond confused. I had to ask the maintainer about this. Turned out they were using something called an AST (abstract syntax tree). This structure maps the relative locations of each section of the file without actually parsing them. You can read more in the maintainer's comment.
With that knowledge in mind and a bit more research, I finally was able to implement this feature. Now I'm still going back and forth with the maintainer regarding error handling, but I'm sure this feature will land soon!
💫 Starchart
Update @aws-sdk/client-route-53 (Link)
I was looking at Starchart yesterday and saw a list of pull requests opened by dependabot, one of which had a failed CI check. I decided to look in a little further. This pull request attempted to update the package @aws-sdk/client-route-53 from 3.360.0 to 3.744.0. That's quite a bit gap in version numbers.
The CI pipeline failed because of a type mismatch. I started by checking the changelog but I didn't notice any changes regarding types.
Fortunately, my IDE was able to help me with locate two new types introduced in the new version:
| RRType | ChangeAction |
|---|---|
/** * @public * @enum */ export declare const RRType: { readonly A: "A"; readonly AAAA: "AAAA"; readonly CAA: "CAA"; readonly CNAME: "CNAME"; readonly DS: "DS"; readonly HTTPS: "HTTPS"; readonly MX: "MX"; readonly NAPTR: "NAPTR"; readonly NS: "NS"; readonly PTR: "PTR"; readonly SOA: "SOA"; readonly SPF: "SPF"; readonly SRV: "SRV"; readonly SSHFP: "SSHFP"; readonly SVCB: "SVCB"; readonly TLSA: "TLSA"; readonly TXT: "TXT"; }; /** * @public */ export type RRType = (typeof RRType)[keyof typeof RRType]; |
/** * @public * @enum */ export declare const ChangeAction: { readonly CREATE: "CREATE"; readonly DELETE: "DELETE"; readonly UPSERT: "UPSERT"; }; /** * @public */ export type ChangeAction = (typeof ChangeAction)[keyof typeof ChangeAction]; |
This part of the code is responsible for managing DNS records. RRType defines the type of DNS record and ChangeAction defines the type of changes to perform on an existing record. While all these types were previously represented by string.
I changed the code to the new types and filed a PR. Later the review came back, suggesting that I create a utility function to handle the type conversion. And this is where I'm at right now.
📝 Conclusion and What's Next
This Sprint felt much more eventful than the last one. In the Hurl project, I was working on a different area of code, which means that more time were spent on search and asking questions. I also made more mistakes because of this unfamiliarity. On the Starchart's side, although I haven't taken much action yet, I suspect there to be more to come:
For the next Sprint, I might need to dial back a little on the Hurl project, since the maintainer mentioned that they have stopped taking in new features until the next release (6.1.0). So my plan is to pick a few bugs to investigate there, while shifting my focus a little more to Starchart.
Top comments (0)