Wrote process_response method. I think the remaining relevant FetchResponseListener methods are process_response_eof (invoked when fetching response is complete) and process_response_chunk (invoked when fetching response body). But process_response_eof requires response trailer support, which is not implemented, and process_response_chunk can probably wait until the response body is implemented.
Turns out when Josh said to create FetchContext later when it’s necessary, he meant literally creating it further down in the method (like physically located further down). Haha oops! I started working on creating FetchContext!
Body
Started implementing the Body functions without ReadableStream. The spec refers to streams a lot, but servo doesn’t implement ReadableStream, so I am trying to figure out how to write things correctly using Vec instead. Set up skeleton code for implementing [text](https://fetch.spec.whatwg.org/#dom-body-text) for dom::Request and dom::Response. Then dug into dom::Response's `text()`, which led to writing bits of `consume_body()`, `run_package_data_algorithm()`, and `utf8_decode()`.
Things we learned:
In order to use Promise::maybe_resolve_native() and the like, it needs a JS Context parameter. JS Context can be obtained through self.global().r().get_cx(). JSContext is a context in which JS can be invoked, and is required by APIs that interact with the JS engine (or it can use a JSRuntime argument). It’s confusing to me, but for now, I’ll just think of it as a connector to the JS world! (probably not 100% accurate).
vec.drain(..3); removes the first 3 elements of a vec.
