This puts them in a new file located at `net_traits/response.rs`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 99689bc6b0531837f1af18ed4b7e4fd765595606
I've been working on making a partial implementation of HTTP-network Fetch[1] so that I can begin testing the entire Fetch protocol as implemented in Servo. The empty steps are intentionally so, including the incomplete Step 5, which I started without realizing I don't need to do basic testing.
[1] https://fetch.spec.whatwg.org/#http-network-fetch
Source-Repo: https://github.com/servo/servo
Source-Revision: 1ea2341a5d6fc3dd38f9557e7620c6ad4dc739a0
This is a rebase of #7842 that also adds a test.
Fixes#4183.
@Yoric, how's this look to you?
Source-Repo: https://github.com/servo/servo
Source-Revision: af1690f3036bc329101bbd6f4e877672d58ca5e0
Addresses #8177
I also noticed some bugs/gaps (and at least one of my TODO's can be an E-Easy)
cc @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: 63923bc7c923587652fb966f1f45009e483b1ebf
This is a pull request for part of https://github.com/servo/servo/issues/6638
It includes the following changes:
-The websocket networking code (ie. making a connection, receiving data, and sending data) has been extracted out of components/script/dom/websocket.rs and into the new file components/net/websocket_loader.rs.
-websocket.rs now communicates with the resource task (components/net/resource_task.rs) to instruct it to initiate a new websocket connection
- websocket_loader.rs now provides an API sent over an IPCChannel that allows websocket.rs to receive feedback about this process and to subsequently send and receive data
Source-Repo: https://github.com/servo/servo
Source-Revision: 951ab565d150b4f108254e06a14ccbe7f1005469
The pull request includes the following task:
* Implemented basic network-level support by adding a member to LoadData that is used by http_loader.rs to conditionally exclude cookies from the HTTP request if the flag is false (default true)
Source-Repo: https://github.com/servo/servo
Source-Revision: 217a55a7854ec3a843bb94f50a8952c61d5fcc2a
Partial #4576. The spec is really getting funky now - it's depending more and more on the DOM objects (e.g. prompting the user for authentication using a `Window` object). I think we can just pass in username and password as properties of the `Request` struct though.
I've also added in the async version for http_request.
Source-Repo: https://github.com/servo/servo
Source-Revision: a515fe320b78758dedcb94848ae7b9a3fbd73fca
This reduces the amount of code using unstable features that we depend on.
The hand-written IP address parser is probably just as fast.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6f35b867c9c3bb7a345e2ac34e5970b93a1d3ea1
This code became dead with the recent CSS loading changes.
Source-Repo: https://github.com/servo/servo
Source-Revision: cd0c8c4e41e9601975c3e8023b36cd66c4ee6b71
Gets rid of a bunch of useless `Cell`/`RefCell` types.
Source-Repo: https://github.com/servo/servo
Source-Revision: 724d4e191b80d84c46cde4a25be9c5f7340e9a06
It was added in commit ecf02a3656d60d4197e7cfc53beaedbc5e1019c0.
Source-Repo: https://github.com/servo/servo
Source-Revision: 61be58a87ff78be6278173d65e8933413041bd00
Partial #4576
I am really unsure of how things would look like, so would really appreciate some feedback on this.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0fc9410f10c1122a05cd36bdf8b7faff12c39555
This is a direct extract from my abandoned PR for a lint (#7546), along with some rather clumsy modifications (only on `components/script/dom/mod.rs` and `components/style/lib.rs`), because I had to sort some of the files again to make peace with tidy, which hasn't been educated about sorting yet!
Source-Repo: https://github.com/servo/servo
Source-Revision: a7208869f2903e36f9b2f540b55b50283d7df466
*The goal of this PR is to get early feedback on this before I go too far down the rabbit hole. This new code path is working, and there's several tests I've written as a proof of concept. There are still some regressions that I'll be fixing in the coming days.*
I've abstracted out the request/response cycle so that it's no longer dependent on the Hyper request/response structs. Since request/response @ hyper are structs, not traits, it made mocking them for tests impossible.
Current issues/concerns:
* This relies on boxing the `HttpResponse` that gets returned from the `HttpRequester` because `HttpResponse` is unsized. I don't know if there's a more idiomatic rust-y way of doing this?
* This relies on boxing the `Read` that is now returned from `load` for the same reason.
* The devtools and resource manager channels are still passed into `load`. It might be easier to inject these as trait dependencies instead of chans as well?
* Needs more tests.
🎩#6727
Source-Repo: https://github.com/servo/servo
Source-Revision: 7dda183022f9bee8b4bdffe8b4cf31e09b885d94
Also adds HeapSizeOf implementations/derive for some types. I've used "Cannot calculate Heap size" as a reason everywhere, because my imagination is rather limited. If you'd like me to change this message for specific types, please write something like this: "Trusted - Cannot calculate Heap size for Trusted" so that it would be easier for me to replace them through a script :)
Source-Repo: https://github.com/servo/servo
Source-Revision: a03616f379c255cc6c9b6e1d04dd7d98bd9926ce
Resolves#6703.
Done:
* [x] When STS headers received, add the host to the HSTS list
Todo:
* [ ] Persist the in-memory list so that it's reloaded on the next browser boot
* [ ] Add tests to `http_loader::load` - it's pretty well completely untested right now, but it's a bit gnarly to untangle and without mocking, it's hard to deal with the dependency on making a real network request. Writing a mock request object should be doable for testing, but there's a lot going on in the function right now.
Source-Repo: https://github.com/servo/servo
Source-Revision: f1c26c59f177570a697c420308fb89d9773c7468
This change makes Servo use serialized messages over IPC channels for resource loading. The goal is to make it easier to make Servo multiprocess in the future. This patch does not make Servo multiprocess now; there are many other channels that need to be changed to IPC before that can happen. It does introduce a dependency on https://github.com/serde-rs/serde and https://github.com/pcwalton/ipc-channel for the first time.
At the moment, `ipc-channel` uses JSON for serialization. This is because serde does not yet have official support for bincode. When serde gains support for bincode, I'll switch to that. For now, however, the JSON encoding and decoding will constitute a significant performance regression in resource loading.
To avoid having to send boxed `AsyncResponseTarget` trait objects across process boundaries, this series of commits changes `AsyncResponseTarget` to wrap a sender only. It is then the client's responsibility to spawn a thread to proxy calls from that sender to the consumer of the resource data. This only had to be done in a few places. In the future, we may want to collapse those threads into one per process to reduce overhead. (It is impossible to continue to use `AsyncResponseTarget` as a boxed trait object across processes, regardless of how much work is done on `ipc-channel`. Vtables are fundamentally incompatible with IPC across mutually untrusting processes.)
In general, I was pretty pleased with how this turned out. The main changes are adding serialization functionality to various objects that `serde` does not know how to serialize natively—the most complicated being Hyper objects—and reworking `AsyncResponseTarget`. The overall structure of the code is unchanged, and other than `AsyncResponseTarget` no functionality was lost in moving to serialization and IPC.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: 2eb122f394651232abd683fc576a5c4288bf277f
This necessitated getting rid of the boxed trait object that was being
be passed between the script task and the image cache task.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: e13ebf712de444132a6cc90f394c121d8d751c4c
The idea here is to land this before making images and canvas IPC-safe,
because this will shake out bugs relating to the shared memory. There
are currently test timeouts that are preventing multiprocess images and
canvas from landing, and I believe those are due to the inefficiency of
sending large amounts of data in the unoptimized builds we test with. By
moving to shared memory, this should drastically reduce the number of
copies and `serde` serialization.
Under the hood, this uses Mach OOL messages on Mac and temporary
memory-mapped files on Linux.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: ed1b6a3513e7546b580693f554a081bc0c7c478a
Implement HSTS (preload-only) servo/servo#6105
* Downloads the HSTS preload list from the chromium repo (same as gecko), then convert it to a list appropriate for servo.
* Reads the preload list when creating a resource task, and implements STS for those domains.
Still todo:
* Read Strict-Transport-Security headers from servers and add details to the in-memory HSTS list. (note: this requires hyper or servo to implement an STS header struct. Hyper seems like the appropriate location, so I will create an issue/PR there soon). The work for this is nearly done with the exception of adding a new ControlMsg and the new header.
* Persist HSTS list to disk with known hosts (perhaps a different issue should be raised for this?)
Source-Repo: https://github.com/servo/servo
Source-Revision: ab3d6c472d409c1602c873dcdcb495a7fec9d4b0
This commit introduces the `serde` dependency, which we will use to
serialize messages going between processes in multiprocess Servo.
This also adds a new debugging flag, `-Z print-display-list-json`,
allowing the output of display list serialization to be visualized.
This will be useful for our experiments with alternate rasterizers.
r? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: ef9715203edf0a280d019b6e8823666f0e7020be
Sorry for not doing it yesterday, I couldn't.
cc @metajack @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 4ebb95ccd8e034007eacb447a054919ef4af2bf7
Fixes issue #6148
@jdm After mulling over this for a little while, i'm not sure if this approach is correct. Any comments?
Source-Repo: https://github.com/servo/servo
Source-Revision: 6595ebed0f50658b8f6d12f9c37017df5ea26efa
...r parsing. Hook up document loading to async networking events.
Relies on https://github.com/servo/html5ever/pull/107, so we'll likely need to backport it rather than wait for the next rustc upgrade.
Source-Repo: https://github.com/servo/servo
Source-Revision: dd319c1a998bbd3eeb84fdc4ca8a41ee7877ca37
This implements a simple load-tracking system and tracks stylesheet loads as an example of how it fits together. This is a simplified and rebased version of #3714; I do not believe that the main thrust of hsivonen's comments (related to tracking navigation in browsing contexts) affect this part of the work.
r? @Ms2ger
Source-Repo: https://github.com/servo/servo
Source-Revision: 2baa69595e2d57213c34b7e168b60885948fa85b
A rebuild after touching components/profile/mem.rs now takes 48 seconds (and
only rebuilds `profile` and `servo`) which is much lower than it used to be.
In comparison, a rebuild after touching components/profile_traits/mem.rs takes
294 seconds and rebuilds many more crates.
This change also removes some unnecessary crate dependencies in `net` and
`net_traits`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 77f653da2c4120ea7ac1a946d97fc70059d513d4
* Simpler image cache API for clients to use.
* Significantly fewer threads.
* One thread for image cache task (multiplexes commands, decoder threads and async resource requests).
* 4 threads for decoder worker tasks.
* Removed ReflowEvent hacks in script and layout tasks.
* Image elements pass a Trusted<T> to image cache, which is used to dirty nodes via script task. Previous use of Untrusted addresses was unsafe.
* Image requests such as background-image on layout / paint threads trigger repaint only rather than full reflow.
* Add reflow batching for when multiple images load quickly.
* Reduces the number of paints loading wikipedia from ~95 to ~35.
* Reasonably simple to add proper prefetch support in a follow up PR.
* Async loaded images always construct Image fragments now, instead of generic.
* Image fragments support the image not being present.
* Simpler implementation of synchronous image loading for reftests.
* Removed image holder.
* image.onload support.
* image NaturalWidth and NaturalHeight support.
* Updated WPT expectations.
Source-Repo: https://github.com/servo/servo
Source-Revision: ac0645c2363b5a6ea3930b0857b3a27f1b6d033f
This implements a framework for opting in to receiving network events asynchronously. It also converts XMLHttpRequest to use them, and paves the way for better support for synchronous XHR using on-demand, targeted event loops instead of spinning the global event loop. This gives us complete feature parity with the existing XHR implementation, using fewer threads than before in the async case.
Source-Repo: https://github.com/servo/servo
Source-Revision: 3151497d498b001b4a783dce0595615c6fc40936
Extracted this out of #5649
This commit was created with the following commands:
```
find . -iname "*.webidl" -type f -print0 | xargs -0 sed -i '' 's/http:\(.*\)whatwg.org/https:\1whatwg.org/g'
```
```
find . -iname "*.rs" -type f -print0 | xargs -0 sed -i '' 's/http:\(.*\)whatwg.org/https:\1whatwg.org/g'
```
Source-Repo: https://github.com/servo/servo
Source-Revision: 4997d3a112354a407365fede1ab1944834a2e13c
