Handle access-control header wildcards
<!-- Please describe your changes on the following line: -->
We were checking Access-Control-Expose-Headers for wildcards inconsistently and then discarding the result; this fixes the check and its use, passing the WPT test for having a wildcard there.
---
<!-- 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#24913
<!-- 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. -->
Use rayon for file operations off the main resource thread
FIX#25723
---
<!-- 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. -->
Upgrade to rustc 1.43.0-nightly (5d04ce67f 2020-02-13)
~This Nightly doesn’t have rustfmt, so merging this PR is blocked on https://github.com/rust-lang/rust/issues/68917 and upgrading to a Nightly with the fix.~
Fixes#25550
Add OpenSSL 1.1.1 build check, Update HSTS Preload list
* This variant also works with cross-compilation. PR should fail in CI on Android at first:
The net crate successfully compiled after switching to OpenSSL 1.1.1 on Android. It seemed openssl.sh doesn't need any changes.(?)
* Updated HSTS preload list and public suffix list.
* Configured OpenSSL [SECLEVEL=2](https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html) like [Debian](https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1) Stable:
> As a result RSA, DSA and DH keys shorter than [2048 bits](16a5a9bb78/docs/BR.md (6153-subscriber-certificates)) and ECC keys shorter than 224 bits are prohibited.
* Although all other crates compile I generally get a `libscript-fe019dd3e0a4e06d.rlib: bad extended name index at 8` error on simpleservo_jniapi, I guess Debian Testing is too new and I just haven't found the right steps so far.
./mach build -d --android
```
= note: /home/darkspirit/github/servo/android-toolchains/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld.gold: error: /home/darkspirit/github/servo/target/android/armv7-linux-androideabi/debug/deps/libscript-fe019dd3e0a4e06d.rlib: bad extended name index at 8
clang: error: linker command failed with exit code 1 (use -v to see invocation)
toolchain: /home/darkspirit/github/servo/android-toolchains/ndk/toolchains/llvm/prebuilt/linux-x86_64/bin
libs dir: /home/darkspirit/github/servo/android-toolchains/ndk/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a
sysroot: /home/darkspirit/github/servo/android-toolchains/ndk/platforms/android-21/arch-arm
targetdir: /home/darkspirit/github/servo/target/android/armv7-linux-androideabi/debug/build/simpleservo_jniapi-26ef18debb5b3630/out/../../..
```
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#25708, fix#25619.
Fix HSTS
The headers crate does not [expose](0c42ad8cf5/src/common/strict_transport_security.rs (L42)) HSTS struct fields. At the moment, it's only usable for HSTS header encoding. An update of the headers crate would require a huge update of http, hyper, hyper_serde, net::decoder as well. Therefore I've copied the `typed_get::<StrictTransportSecurity>` decoding feature for now, but with exposed struct fields. Let's remove this custom struct with the next hyper upgrade. I tried to prevent needless HSTS database lookups when network.enforce_tls.enabled is set.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#14363, fix#20120.
- [x] There are tests for these changes
Let hyper automatically set the host header if needed
Google's gws web server did not expect to receive an unneeded Host header via HTTP/2, therefore it responded with 400 Bad Request over a working HTTP/2 connection.
https://tools.ietf.org/html/rfc7540#page-55
> Clients that generate HTTP/2 requests directly SHOULD use the ":authority" pseudo-header field instead of the Host header field.
It's hyper's job to take care of this for the HTTP/1 case, therefore we can remove old code.
When calling [Client::builder()](1974c875a1/components/net/connector.rs (L116-L119)) we do not disable hyper's default [set_host](4b6099c7aa/src/client/mod.rs (L1019-L1024)) config option, therefore hyper [automatically adds a Host header for non-HTTP/2 connections](4b6099c7aa/src/client/mod.rs (L289-L292)) based on the [URI](3f663d7ab2/components/net/http_loader.rs (L418-L421)).
r? @jdm
---
<!-- 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#25286.
Add start_time to resource timing.
<!-- Please describe your changes on the following line: -->
`start_time` property added to `ResourceFetchTiming`, which enables the setting of `start_time` in the `PerformanceEntry` member of `PerformanceResourceTiming`.
Following the specification at https://w3c.github.io/resource-timing/#dfn-starttime, `start_time` is set to the value of `redirect_start` if redirection occurs and the timing allow check passes. Otherwise it has the same value as `fetch_start`.
---
<!-- 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#21254
<!-- 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. -->
This needs a lot more hooks before it'll actually be a good
implementation, but for a start it can help get some feedback on if this
is the right way to go about it.
Part of servo/servo#4577
Add secure connection start
Implementing `secure_connection_start` as well as we can, this is related to #21268
We are setting the value as well as we can since we don't have a way to know if we are currently using a secure transport or where the handshake before the connection is done as the spec says on the step 15 [https://w3c.github.io/resource-timing/#sec-process](https://w3c.github.io/resource-timing/#sec-process)
Regarding the Timing Allow Check, that's being done on another PR by another person which will take care of setting the rest of the values on `PerformaceResourceTiming` to Zero and prevent them to set them any other way.
I'm currently setting the `secure_connection_time` using `precise_time_ms()` as the `connection_start` and `connection_end` are set that way... but other attributes inside `PerformanceResourceTiming` are set using `precise_time
Another thing, the issue talks about setting `redirect_start` but I'm not really sure if it's related, if so I can look up into that too... I might have just read and thought it was all about secure connection start.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix#21268
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because ___
<!-- 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/23990)
<!-- Reviewable:end -->
Fetch: ensure consistency between response, done-chan, and cache state.
This ensures that when a cached response is not used because it requires revalidation, the done chan is set back to `None`(since the cache might have set it to `Some` when constructing the response requiring revalidation).
<!-- 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: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix#24399 (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. -->
<!-- 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/24401)
<!-- Reviewable:end -->
Websocket: use ipc router to handle ws dom-action messages
<!-- Please describe your changes on the following line: -->
Use the ipc router as opposed to spawning a dedicated thread.
---
<!-- 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. -->
<!-- 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/24402)
<!-- Reviewable:end -->
Allow using CORS filtered image responses as WebGL textures
More specifically, this makes the "is this image same origin?" check consider the CORS status of the original response, rather than relying on an overly-strict "is this image's response's URL same-origin with a particular global?" check. To do this, we make the image cache double keyed based on the requested URL as well as the requesting origin, and store the CORS status of the eventual response with the final image that eventually gets sent to the HTMLImageElement consumer.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#24330 and fix#24368
- [x] There are tests for these changes
<!-- 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/24340)
<!-- Reviewable:end -->
Cache crossorigin test
This adds a test for #24356 to ensure that we don't regress our cache behaviour.
---
- [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
<!-- 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/24370)
<!-- Reviewable:end -->
