diff options
author | bors-servo <lbergstrom+bors@mozilla.com> | 2016-02-18 05:54:51 +0530 |
---|---|---|
committer | bors-servo <lbergstrom+bors@mozilla.com> | 2016-02-18 05:54:51 +0530 |
commit | 88afe38092b9bb6320d01c94a9a239e8be284933 (patch) | |
tree | 370152758c40b16bd5819068d228573a944773a1 /components/layout/query.rs | |
parent | 63dc161b773775c6755a604ec04b81c0bc479bf3 (diff) | |
parent | cf607606e09e07e60c946d084778802a8b307cef (diff) | |
download | servo-88afe38092b9bb6320d01c94a9a239e8be284933.tar.gz servo-88afe38092b9bb6320d01c94a9a239e8be284933.zip |
Auto merge of #9608 - nikkisquared:implement_http_redirect_fetch, r=jdm
Implementation of HTTP Redirect Fetch step
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
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9608)
<!-- Reviewable:end -->
Diffstat (limited to 'components/layout/query.rs')
0 files changed, 0 insertions, 0 deletions