<!-- Please describe your changes on the following line: -->
Implemented [nosniff](https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff?) for [fetch algorithm](https://fetch.spec.whatwg.org).
---
<!-- 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#14521 (github issue number if applicable).
<!-- 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: 5662af9057557ee3db3b9766b0ef0d3fa11dcbb2
<!-- Please describe your changes on the following line: -->
This PR adds a serializable type `ImmutableOrigin` and a non-serializable type `MutableOrigin`. The immutable type represents an origin with `null` domain, and the mutable type represents an origin with a mutable domain. This separation is needed for implementing setting `document.domain`.
---
<!-- 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#14892.
- [X] These changes do not require tests because it's a refactoring which will enable other features.
<!-- 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: 78e8c31a4d1890260dda83f2db85672f693c1e97
Implemented response validation part of https://w3c.github.io/webappsec-subresource-integrity/.
Implemented step eighteen of the main fetch. If a request has integrity metadata, then following steps are performed
1) Wait for response body
2) If the response does not have a termination reason and response does not match request’s integrity metadata, set response and internalResponse to a network error.
Dependency updated: html5ever-atoms from 0.1.2 to 0.1.3. This will not completely fix#14523, It will implement changes related to response validation. Request validation algorithm implementation needs CSP.
I did not update any WPT-Test. In my local system, I found some assertion issue dependent on the order of execution of test-case. It would be helpful if someone could do "try" build on these changes to get wpt results.
r? @jdm
<!-- 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
<!-- 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: f958dafcaeed643f1232a23f5c2d4f6ba141bfea
Implemented step nine of the main fetch. If current URL scheme is 'HTTP' and
current URL's host is domain and if current URL's host matched with Known
HSTS Host Domain Name Matching results in either a superdomain match with
an asserted includeSubDomains directive or a congruent match then we
change request scheme to 'https'. This change has been made in method.rs
A test case to validate this has been added in fetch.rs. For asserting
https scheme, a https localhost was required. For this purpose I have
created a self-signed certificate and refactored fetch-context and
connector.rs to programmatically trust this certificate for running this
test case.
This should fix https://github.com/servo/servo/issues/14363
<!-- 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#14363
<!-- 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: c7991d596f7453d09c2b2a98eecce72f182a4e24
<!-- Please describe your changes on the following line: -->
Add check for bad ports to http_fetch(), return NetworkError::Internal if bad port/schema combination is seen.
Test added
---
<!-- 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#14514 (github issue number if applicable).
<!-- Either: -->
- [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: de7d73adb0a51627e4aaa568787fe36c22029bd3
<!-- Please describe your changes on the following line: -->
This PR removes the `util` crate.
* Replaced the `spawn_named` and `clamp` functions by appropriate uses of `std:🧵:Builder::spawn`, `std::cmp::min` and `std::cmp::max`.
* Moved `opts`, `prefs` and `resource_files` into a new `config` crate.
* Moved `remutex` and `geometry` into their own crates.
---
<!-- 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 do not require tests because they are refactorings
<!-- 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: 4eb653817f87e5fb47de34356f558eb76ecbca9f
<!-- 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 stores the FrameId as well as the PipelineId in an html iframe. The iframes are now responsible for creating frame ids, not the constellation.
This is the first step in fixing #633, because it means we know the frame id of each script thread when it is created. It also means we can share the frame id, for example using it in the debugger.
cc @jdm, @ConnorGBrewster and @ejpbruel.
---
<!-- 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 do not require tests because it's a refactoring.
<!-- 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: d01a8662154924a551c8d7a2f12b22bcaf998a7c
<!-- Please describe your changes on the following line: -->
The spec removed it. Check the scheme instead, data is always same origin now,
except for workers.
Closes#13362
---
<!-- 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#13362 .
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they only remove code.
<!-- 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: e494dedce5e5215d6d0953ab28668825234237dc
Replace most uses of the word "referer" with "referrer", except for `hyper::header::Referer`. Also update the unit tests to compile & pass after those changes.
---
<!-- 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#13286
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because they're only typo fixes.
<!-- 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: 8ccfffaa774a05fa12db09c872cc59c4bf070ab2
<!-- 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
Solved wrong referrer policy in cors_preflight_fetch
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#13026
- [X] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: f66382f75c80c7d8141c30348304600e5155b057
<!-- Please describe your changes on the following line: -->
Added devtools support for fetch for XHR, but devtools can't show the request in the XHR tab. I've attached a picture of an XHR request in devtools.
<img width="694" alt="screenshot 2016-07-19 11 07 55" src="https://cloud.githubusercontent.com/assets/11877868/16944480/210b0e8a-4da1-11e6-8288-48005ede33f6.png">
---
<!-- 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#11774 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because I don't know how to automate devtools testing for this
<!-- 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: b5fe7db8b451f86777fb5c8d1f086319be8170c2
<!-- 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#12520 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because it's a refactoring
<!-- 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: a39bd7db5ba26fa3c95e4bbbb5f1a358bc01965f
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes do not require tests because only silent some warnings
Source-Repo: https://github.com/servo/servo
Source-Revision: 95941cb4dff6d4cb30375b54624f0b5acb4d81f1
<!-- 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
Fixes#10904
Note that the related web-platform-tests failed both before and after this commit
Source-Repo: https://github.com/servo/servo
Source-Revision: 3128a71ac703bf7579f0fcac9d03655756e8b6c7
The current logic for a cors cache match does not consider "credentials is false and request's credentials mode is not "include" or credentials is true."
I could have missed something, but `CacheRequestDetails::credentials` is set to true if credentials mode is "include", and false otherwise. So `(!cors_cache.credentials && !cors_req.credentials) || cors_cache.credentials` would be directly following the spec, but unless I'm mistaken `cors_cache.credentials || !cors_req.credentials` is logically the same.
Fixes: #10525
Source-Repo: https://github.com/servo/servo
Source-Revision: 3d38a60cee8a2e19ae8f04df7c2374fc9d97999c
Fixes#10165
jdm mentioned of decoupling the, payload loading mechanism to data_loader.rs. So accordingly a `decoder` method has been added to data_loader.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9f892edd87441393e5de00790a5abb7fc93a09de
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.
Fixes#10147.
Test with: `./mach test-unit -p net fetch::test_fetch_with_local_urls_only`
Source-Repo: https://github.com/servo/servo
Source-Revision: 38e8c923b519f488cd0614ff9409997998418cc7
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
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
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
