<!-- Please describe your changes on the following line: -->
- [X] make the memory cache data structure derive MallocSizeOf
- [X] add a new IpcReceiver argument to ResourceChannelManager::start that is used for listening to messages from the memory profiler (it must correspond with this sender)
- [X] use run_with_memory_reporting in the network code to register a memory reporter for that thread
- [X] when a message from the memory profiler arrives, create a report that includes that size of the public and private http caches
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [x] These changes fix#19251 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 8f226f841bd5e1ab412ff2cd8417919b222f7555
<!-- Please describe your changes on the following line: -->
@jdm @KiChjang @Manishearth Follow up on https://github.com/servo/servo/pull/18676 and https://github.com/servo/servo/pull/19274 to ignore aborted responses in caching.
I also found out the cache shouldn't return any response whose body is still in `ResponseBody::Receiving` mode, because that fails the assertion at https://github.com/servo/servo/blob/master/components/net/fetch/methods.rs#L438(we might want to add a channel as pat of the cached response later on to deal with this case). I only found out now because I needed the response from the server to trickle in so that it could be cached and aborted.
I copied the `http-cache.py` server from the wpt folder, and added a 'trickle' option, which is necessary to actually have a failing test with a cached but aborted request, it's now passing.
I also remove one unused import that slippled through previously.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 4307b6e67b0cb35e2afc46ba0b64e7bc5bde1bdf
This PR implements cancellation for fetch, and uses it for XHR. This means that fetch clients can now send a message to the fetch task asking for the network request to be aborted.
Previously, clients like XHR had abort functionality but would implement it by simply ignoring future messages from the network task; and would not actually cancel the network fetch.
Source-Repo: https://github.com/servo/servo
Source-Revision: 00b3612fe9045f1cb6ba6c89ba7801642a6fa2c9
Servo currently uses `heapsize`, but Stylo/Gecko use `malloc_size_of`.
`malloc_size_of` is better -- it handles various cases that `heapsize` does not
-- so this patch changes Servo to use `malloc_size_of`.
This patch makes the following changes to the `malloc_size_of` crate.
- Adds `MallocSizeOf` trait implementations for numerous types, some built-in
(e.g. `VecDeque`), some external and Servo-only (e.g. `string_cache`).
- Makes `enclosing_size_of_op` optional, because vanilla jemalloc doesn't
support that operation.
- For `HashSet`/`HashMap`, falls back to a computed estimate when
`enclosing_size_of_op` isn't available.
- Adds an extern "C" `malloc_size_of` function that does the actual heap
measurement; this is based on the same functions from the `heapsize` crate.
This patch makes the following changes elsewhere.
- Converts all the uses of `heapsize` to instead use `malloc_size_of`.
- Disables the "heapsize"/"heap_size" feature for the external crates that
provide it.
- Removes the `HeapSizeOf` implementation from `hashglobe`.
- Adds `ignore` annotations to a few `Rc`/`Arc`, because `malloc_size_of`
doesn't derive those types, unlike `heapsize`.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix https://bugzilla.mozilla.org/show_bug.cgi?id=1409255
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because testing is on the Gecko side.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 4c538b642e4bdfbf42c522c5a59c258a6d14546e
<!-- Please describe your changes on the following line: -->
Automatically verify that derive() lists are alphabetically ordered #18172
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#18172 (github issue number if applicable).
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 474369618965569407d127b1e8c481e757cc59d3
Includes updates to main fetch, scheme fetch, HTTP fetch, HTTP-redirect fetch, HTTP-network fetch, HTTP-network-or-cache fetch and CORS preflight fetch.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9f64630eaa5731db10b113ce0a2b967dbc4de15a
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#14596 .
r? @jdm
I ran some tests at random from the `navigating-across-documents` folder, and they are passing.
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: eac4f407e2bfa0055a698ca438972566f0814e43
<!-- Please describe your changes on the following line: -->
Avoids mapping response types that are distinct according to [the spec](https://fetch.spec.whatwg.org/#concept-response-type) to fewer response types. Also updates test expectations to match that we now pass tests that check the response type.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#14068
<!-- Either: -->
- [X] There are tests for these changes
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: f1c82be0e61df679db25199ac3e7afc4be5d141f
<!-- Please describe your changes on the following line: -->
Still needs a bunch of code in net to be converted in order to get more
advantage of this for images and stuff, but meanwhile this should help quite a
bit with #13778.
Still wanted to get this in.
r? @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 22aebdf5d41a3509cd6515ccf5edcdf33715a76d
<!-- Please describe your changes on the following line: -->
This PR adds the [dom::Response](https://fetch.spec.whatwg.org/#response-class) implementation and addresses #11896.
The relevant passing tests` expectations have been updated.
In order to allow non-UTF-8-encoded status messages, `net_traits::response::Response`'s `raw_status` field has been changed from type [`Option<RawStatus>`](https://doc.servo.org/hyper/http/struct.RawStatus.html) to type `Option<(u16, Vec<u8>)>`. As a result, a few other files which rely on the `raw_status` field were affected and updated.
TODOs:
- The `body` and `trailer` methods. Relies on implementation of `ReadableStream` and `Promise`s.
- Similarly, replace the dummy constructor `_body: Option<USVString>` argument with `body: ResponseBodyInit`.
- Currently, whenever `r's response's header list` or `r's Headers object` are mentioned, I always modify the `headers_reflector` field (of type dom::Headers, or `r's Headers object`) and not the corresponding hyper::Headers list in the net_traits::Response field. A completely accurate interpretation of the spec might consider making both of these lists the same thing via a reference. [Discussion](https://github.com/whatwg/fetch/issues/358) was [had](https://github.com/servo/servo/pull/12884).
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 5a5a76cc5db830d2e622d4e0924837383b64dfa2
<!-- Please describe your changes on the following line: -->
Moves XHR over to the fetch backend.
Previous PR: https://github.com/servo/servo/pull/114
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors (Will fix later)
<!-- Either: -->
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 0c11e8340b26aa86faf9ea40aae253392b338ba3
This automates something that I find myself frequently commenting on in PRs.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] There are tests for these changes OR
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 3ec20d9cf517c67f4d280e8958cc58c4c2b4fbb2
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.
Source-Repo: https://github.com/servo/servo
Source-Revision: 95883dcbcfe10104c7a78ac532cb9aeb4bda855f
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
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
Fixes#8544
No test yet. Is there a way to mock a https connection?
Also, I wish I could use the `HTTPSState` enum instead of a `String` when calling `trigger_mozbrowser_event` (https://github.com/servo/servo/compare/master...paulrouget:securitychange?expand=1#diff-30a18e04d7e0b66aafdf192e416cad44R306) but that would require `constellation_msg.rs` to know about `HTTPSState`, which is defined in `document.rs`, which would add a dependency to `components/msg`. I could define `HTTPSState` somewhere else maybe? Or maybe it's fine to use a `String`. But then, should I use the HTTPSState strings (`"modern/deprecated/none"`) or the mozbrowser strings (`"secure/insecure/broken"`) (as it is now)
Source-Repo: https://github.com/servo/servo
Source-Revision: 3d63f09361afa80b9d5c4f6b192c9bd8936094b7
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
Similar to why I'm doing #9172, I'm changing `Rc<RefCell<Response>>` into `Rc<Response>` and wrapping fields in `RefCell<T>` as needed. So far I've only needed to change `url_list`, but I'm sure I'll need to update more fields in the future.
There's two lines that don't compile that I'm not going to bother trying to fix until #9172 is approved, because getting them to work now will just require more changes after merging with the changes #9172 makes to them.
Source-Repo: https://github.com/servo/servo
Source-Revision: b8186a2203cdbdcc24d77554cb53e048ef13c669
This puts them in a new file located at `net_traits/response.rs`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 99689bc6b0531837f1af18ed4b7e4fd765595606
