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).
In function Request::fetch_main, flag local_urls_only (if set)
should allow fetching local urls only. Before this change, the flag had
the inverse behaviour.
Add Tests For Asynchronous Fetch Calls With Filtered Responses
I've added two tests using async_fetch intended to create filtered responses. I caught and fixed a bug where waiting for response.body to be completed would never pass for Opaque or OpaqueRedirect, since their response.body is always `Empty`.
As always, I'd appreciate review and feedback! I don't plan to write new tests, but I will gladly patch up any gaps in the current tests.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9907)
<!-- Reviewable:end -->
correctly send secure cookies after hsts url match
Fixes#8100, where sites in the hsts list were not recieving secure
cookies if the site was originally loading using a plain http url.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9780)
<!-- Reviewable:end -->
Make Fetch Protocol Asynchronous
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.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9753)
<!-- Reviewable:end -->
Validate MIME pattern checking
The MIME detector for a HTML file contains an additional byte in the mask. While it doesn't hurt, it is not used in the byte matching code (since it is zipped with the `pattern` iterator).
I'm not clear how to test this within the `servo` code. The fix doesn't change any externally visible behavior. A test to validate the `ByteMatcher` structures would require the private ByteMatcher structures to be visible to the test. I could use a sub-module, as described at https://doc.rust-lang.org/book/testing.html#the-tests-module but this pattern doesn't appear anywhere else in the `servo` code.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9631)
<!-- Reviewable:end -->
This adds a size to the test webp file, since the error fixed occurs
when the test object is the same length as the matched pattern, and
is not equal to the pattern.
Add methods to move ByteStrings underlying bytes
Add methods to move the underlying `Vec<u8>` for `ByteString`.
I saw this as at least two methods. One to "move and replace with and empty Vec<u8> (`bytes`), and one to take ownership of the whole object (`own_bytes`). I typically also don't like adding methods with out unit tests. If you think they're unnecessary, just let me know.
As always, please let me know if you have any comments, critiques, or nits!
Fixes#9655
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9684)
<!-- Reviewable:end -->
Add WebRender integration to Servo.
WebRender is an experimental GPU accelerated rendering backend for Servo.
The WebRender backend can be specified by running Servo with the -w option (otherwise the default rendering backend will be used).
WebRender has many bugs, and missing features - but it is usable to browse most websites - please report any WebRender specific rendering bugs you encounter!
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9589)
<!-- Reviewable:end -->
WebRender is an experimental GPU accelerated rendering backend for Servo.
The WebRender backend can be specified by running Servo with the -w option (otherwise the default rendering backend will be used).
WebRender has many bugs, and missing features - but it is usable to browse most websites - please report any WebRender specific rendering bugs you encounter!
Implementation of HTTP Redirect Fetch step
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
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9608)
<!-- Reviewable:end -->
This commit refactors the style crate to be completely independent of
the actual implementation and pseudo-elements supported.
This also adds a gecko backend which introduces parsing for the
anonymous box pseudo-elements[1], although there's still no way of
querying them.
https://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSAnonBoxList.h
Test filtered responses and implement Cors Check Fetch step
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.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9525)
<!-- Reviewable:end -->
