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
components/script/dom/bindings/global.rs modified -> all *_thread_source occurrences renamed to *_task_source to comply with spec
Source-Repo: https://github.com/servo/servo
Source-Revision: 63dc161b773775c6755a604ec04b81c0bc479bf3
Addresses both cookies in request and response. Resolves#9540.
Source-Repo: https://github.com/servo/servo
Source-Revision: bc034845b7e543e4e71fa21d6bf99e9f10ddb6c5
A basic implementation of `RootedReference for Option<JS<T>>` based off of
other implementations of `RootedReference` for `Option` wrapped types.
Really I just wanted an excuse to read more in `bindings` 😄 Let me know
if you have any comments or critiques.
Fixes #9654
Source-Repo: https://github.com/servo/servo
Source-Revision: ab381cf951f3e556d0f4c1f2107a311b0d275f91
Fix check to set flag if any header is not a simple header, rather than only if all
headers are simple headers.
Fix failing tests to allow merge in advance of @nikkibee's changes
as per @jdm's direction via IRC.
Source-Repo: https://github.com/servo/servo
Source-Revision: 949a2d3d11d41912fb30e2d152045beb8c2aeebc
The background behind why I'm submitting this PR is slightly embarrassing. After running `./mach` with some servo options I got the following stack backtrace.
```
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: ParseIntError { kind: InvalidDigit }', ../src/libcore/result.rs:746
stack backtrace:
1: 0x56459001b0b0 - sys::backtrace::tracing:👿:write::hb120982054a416e35nu
2: 0x56459001e02b - panicking::default_handler::_$u7b$$u7b$closure$u7d$$u7d$::closure.42840
3: 0x56459001dc96 - panicking::default_handler::h7ae2e4523ef4c187IFy
4: 0x56459000760c - sys_common::unwind::begin_unwind_inner::h5fb19481d14902dbDgt
5: 0x564590007cf8 - sys_common::unwind::begin_unwind_fmt::hd62d57279546b0f2Jft
6: 0x56459001a701 - rust_begin_unwind
7: 0x56459004c01f - panicking::panic_fmt::h27f7225e08792f40qYL
8: 0x56458f393901 - result::unwrap_failed::h18215968003310890981
at ../src/libcore/macros.rs:29
9: 0x56458f3937b9 - result::Result<T, E>::unwrap::h10319050269194353824
at ../src/libcore/result.rs:687
10: 0x56458f383701 - opts::from_cmdline_args::h8ea8d8c87dc6ee726lg
at /home/drobertson/git/servo/components/util/opts.rs:599
11: 0x56458d1f8cdf - main::h8517eb49d15e90fbNaa
at /home/drobertson/git/servo/components/servo/main.rs:53
12: 0x56459001d8f4 - sys_common::unwind::try::try_fn::h9076850075504893162
13: 0x56459001a68b - __rust_try
14: 0x56459001d36e - rt::lang_start::h58a22f304b0c1e19Oxy
15: 0x56458d2f4aa9 - main
16: 0x7f370496360f - __libc_start_main
17: 0x56458d1c04a8 - _start
18: 0x0 - <unknown>
Servo exited with return value 101
```
I immediately opened up `gdb` and got to work only to realize that the error was due to a typo in an option that had been `unwrap`ed at [components/util/opts.rs:599](https://github.com/servo/servo/blob/master/components/util/opts.rs#L599). Perhaps some more informative error messages will help prevent some future face-palm moments like mine 😄
I couldn't think of a good way to add tests for this. Please let me know if I missed something. Comments and critiques are welcome!
Source-Repo: https://github.com/servo/servo
Source-Revision: 7aedb9c7cdcc1b67c1d6d01f36f2fe7c1a17ddac
My first attempt at implementing the Blob response for XMLHttpRequest. The expected result for the response `tests/wpt/web-platform-test/HMLHttpRequest/response-blob-data.htm` is also changed to `PASS`. Please let me know if you see any areas in which I can improve this PR!
Fixes#9623
Source-Repo: https://github.com/servo/servo
Source-Revision: e8ae7e47731eb20ea36dbc55deda84b664c3aab4
This allows, among other things, having different implementations for parsing pseudo{elements, classes} in both `ports/geckolib` and in servo.
Source-Repo: https://github.com/servo/servo
Source-Revision: c11844cbf28054784c8d65781cff20045d8ee48b
The calculation of MP4 frame length is incorrect, shifting values by 1 bit instead of 8 bits. It works for the test MP4 file because the length of the frame is less than 256 bytes, so the shifted values are all zero.
This PR changes the code to calculate the length correctly. It adds a test to check a fake long stream. Still not long enough to test completely, but at least detects the problem with the original code.
Source-Repo: https://github.com/servo/servo
Source-Revision: 520ca258d4f979500f839e13a278bee35bfcc00a
It occurs to me as I write this that this doesn't handle the case of removing the iframe from the document before it's finished loading. Consider this an early feedback release!
Source-Repo: https://github.com/servo/servo
Source-Revision: a31f31e81977be5215f31851885e8ab46890c556
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#9556.
This makes Servo compile with one warning less.
Source-Repo: https://github.com/servo/servo
Source-Revision: cb8be1434f61e6bfe4639d42b1422329b0451a47
This ensures that UncheckedUnwrap(obj, /* stopAtOuter = */ true) will indeed
stop at the WindowProxy ("outer window", in older SpiderMonkey jargon), which
is necessary to prevent raw Window ("inner window") objects becoming visible
to JavaScript code, or tripping assertions that we don't do that.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2d1293d54d58e6aa72312edd53aac4e9af5892b6
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
