When fetching about:blank, response body should be the empty byte
sequence.
Spec: https://fetch.spec.whatwg.org/#concept-basic-fetch
Before this change, response body would be set to `ResponseBody::Empty`,
and then fetching would result in an infinite loop at step 19 in fn
`main_fetch` (methods.rs).
r? @KiChjang
Source-Repo: https://github.com/servo/servo
Source-Revision: 446783f7b6f0b55164b3b3c3e8be90c2b392cf97
There is no real reason to put this in an extension trait.
Source-Repo: https://github.com/servo/servo
Source-Revision: ebe7d9ebfb28d484ff0cce4e70cb8809f5867af5
Following having finished making Fetch asynchronous, response.body should be set asynchronously, since it's the major goal of calling Fetch. So far, I've made the body wrapped in Arc<Mutex<>>, and I've wrapped a new thread around the part where it's set. I've also discovered that the fetch_async function makes step 8 of Main Fetch obsolete, and I've commented it appropriately.
I'm currently having a hard time with the thread for setting response.body, though. @jdm suggested I have the body set continually, block by block, but my implementation for that runs so slow that I can't finish running my fetch test suite in reasonable time. @KiChjang pointed out that a lot of the lag is due to how response.body currently stores everything inside a Vec. Changing the storage container seems to be both necessary and beyond the scope of the time I have to work on this.
Source-Repo: https://github.com/servo/servo
Source-Revision: fee7cb179ee7ba2f159d87af07afaf0cd99a2161
I'm working on making it possible to run Fetch Asynchronously, as required for some steps, such as Main Fetch. It looks like somebody has already laid some groundwork for that, with a AsyncFetchListener trait and two async fetch functions defined, which I'm building on top of.
So far, as a sort of proof of concept, I've written a test to asynchronously retrieve a fetch response, which uses a simple function to check if the fetch response is complete or not. I'd like to be checked if I'm on the right path, to see if I need to rework anything so far, and what my next step can be.
Source-Repo: https://github.com/servo/servo
Source-Revision: 22ce878edc22360af7391694efc9e5668116d3fb
This should make fetch match the spec more closely.
Source-Repo: https://github.com/servo/servo
Source-Revision: 4e244b16dd3c050a8d6b24ee9209caf116462317
I've made a first draft of a complete implementation of HTTP Redirect Fetch, most of which is just refactored out of HTTP Fetch. I've also made some minor changes in a few other steps, all collected in the second commit, based on recent changes to the Fetch Standard. Since HTTP Redirect Fetch is so new, I figured now would be a fine time to make those other changes.
The biggest thing on my mind right now is how the spec says[1] "This algorithm will be used by HTML's "navigate" algorithm in addition to HTTP fetch above." This makes me think that this function, as well as HTTP Fetch, need to public, or at least have a public-facing function- since each Fetch function takes an Rc<Request>, which might be weird to require callers to supply.
[1] https://fetch.spec.whatwg.org/#http-redirect-fetch
Source-Repo: https://github.com/servo/servo
Source-Revision: 88afe38092b9bb6320d01c94a9a239e8be284933
I've been writing tests for creating filtered responses. So far I have three of the four types being made (namely, Basic, CORS, and Opaque), and just need to figure out how to make an OpaqueRedirect filtered response, since it's handled separately from the others. I will also add more tests to ensure the content of the filtered responses matches the limitations placed by the specification.
Along the way I implemented Cors Check, since it's required for the CORS filtered response. @jdm suggested I handle it in here, since it's such a small step, compared to other parts of Fetch.
Since all the tests currently pass, and I've spent a while adding the Cors Check and other pieces, I figured now would be a good time to start having it reviewed.
Source-Repo: https://github.com/servo/servo
Source-Revision: f1018b84a838ec8505f6a0bcb6e13286ce80a95c
I started out with Step 11 of Main Fetch so I could test creating filtered responses, which broke my tests that compare the Fetch result to a message on a server. I realized that if I got the tests to work, I'd likely end up breaking them again with the next step of Main Fetch I added, so I went ahead and did as much of Main Fetch as I could figure out.
Some steps I'm sure I could implement, I just don't know how. Such as when the spec says to "wait for response", or how to implement a Runnable object (which iirc is what I need to use) to run everything after Step 8 in parallel.
The fetch tests are still not running correctly, but I sure it's because they're getting a filtered response which doesn't have the body of response. I'm not sure how to handle that, whether it means a change needed in the tests or in the Fetch code. Like always, I look forward to feedback on my work!
Source-Repo: https://github.com/servo/servo
Source-Revision: f0122efcec30594014c5db9a9647098701195532
I've written two new tests for Fetch: one to test the highest possible number of redirects succeeds; and another to ensure a failure in Fetch by requesting too many redirects. I also wrote a helper function to be used by each test, since the main difference is how many times they try to redirect.
I've also changed the check against redirect_count in http_network fetch to compare it as greater than or equal to 20, as opposed to being only equal to 20. That's outside of the spec, but in my experience testing for pure equality can easily create errors. Even though it's technically not possible for redirect_count be above 20, bizarre bugs during runtime certainly happen.
Source-Repo: https://github.com/servo/servo
Source-Revision: c80fa3386459efd27b64c8b6cab33794e66d082b
I've updated http_fetch to now set response.body, as well as written a test to ensure that fetch can retrieve a message on a server. I've also looked into partially implementing some more of http_fetch while trying to figure out where response.body gets written to.
As always I'd like feedback on my logic, I'm confident there are more steps for handling response.body I need but I find the specification difficult to parse on this.
Source-Repo: https://github.com/servo/servo
Source-Revision: 175b3c2d271cdfdfcac4c3daf5cde3060748b0b8
…to net_traits.
Also updated unit tests to correctly reference and use Request and Fetch methods.
This is in preparation for XHR and EventSource (possibly WebSocket as well), which rely on using Request, but we cannot make the script crate depend upon the net crate.
cc @nikkisquared @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: ce0b89d310212aaaa66b759c7c2548fb2f9a2738
