Sometimes clippy gets outdated by months, and its current support setup
means that each Servo component need to opt into it by depending on
the plugins crate manually, and not all components do that.
Fix loss of response type information in Fetch API
<!-- 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. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/14868)
<!-- Reviewable:end -->
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
*Wait for response body
*If the response does not have a termination reason and response does not
match request’s integrity metadata, set response to a
network error.# Please enter the commit message for your changes. Lines starting
Refactored HSTSList to use HashMap, where the key of HashMap is the base
domain. Every time when we check if a host is secure, we find the base
domain of the host and get a vector of HSTS entries associated with the
base domain.
While this will not give O(1) look up time, we would have a smaller list
to iterate for every lookup. I have added one unit test to validate
HashMap changes.
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.
<!-- 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. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/14623)
<!-- Reviewable:end -->
fetch() returns immediately after processing EOF, at the latest, so not
spinning up a thread should not cause noticeable delays. OTOH, it might
reduce the contention for cores, and reduce the overall time needed.
CookieStorage has been refactored to use HashMap with base domain as the
key. Values of hashmap is vector of cookies.
CookieStorage now has max_per_host which restricts maximum cookies that
can be added per base domain.
Cookie eviction doesnot take place if max_per_host is not reached.
Cookie eviction logic implemented here does following steps
1) Evict all expired cookies
2) Remove oldest accessed non-secure cookie If any
3) When no non-secure cookie exist, remove oldest accessed secure cookie
if new cookie being added is secure. Else ignore new cookie
The change to the unit test is necessary because the resource thread is not
resilient against either of these Senders being dropped while the resource
thread is running. Before this change, it held clones of those senders itself
(public_setup_chan_clone, private_setup_chan_clone).
