Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upFix logic for cors cache match #10867
Conversation
highfive
commented
Apr 27, 2016
|
Heads up! This PR modifies the following files:
|
highfive
commented
Apr 27, 2016
| @@ -112,7 +112,7 @@ pub struct BasicCORSCache(Vec<CORSCacheEntry>); | |||
| fn match_headers(cors_cache: &CORSCacheEntry, cors_req: &CacheRequestDetails) -> bool { | |||
| cors_cache.origin == cors_req.origin && | |||
| cors_cache.url == cors_req.destination && | |||
This comment has been minimized.
This comment has been minimized.
KiChjang
Apr 27, 2016
Member
Hmm... spec says "url is request's current url", so I'd expect to see something like cors_cache.url == cors_req.current_url() instead.
This comment has been minimized.
This comment has been minimized.
dlrobertson
Apr 27, 2016
Author
Contributor
Great point. Didn't think to question that since the Issue was focused on the later logic. After looking at CacheRequestDetails, destination is the only Url member. Is destination used as the "current URL" in here?
This comment has been minimized.
This comment has been minimized.
KiChjang
Apr 27, 2016
Member
Wait, sorry. I didn't notice that cors_req is an instance of CacheRequestDetails, so the code as it is is fine.
This comment has been minimized.
This comment has been minimized.
|
@bors-servo r+ |
|
|
|
@bors-servo: r- |
|
No problem. Where are the cors tests? |
|
For the fetch code, it's |
|
Review status: 0 of 4 files reviewed at latest revision, 2 unresolved discussions. components/net/fetch/cors_cache.rs, line 153 [r2] (raw file): Comments from Reviewable |
| @@ -40,6 +40,10 @@ pub fn fetch_async(request: Request, listener: Box<AsyncFetchListener + Send>) { | |||
|
|
|||
| /// [Fetch](https://fetch.spec.whatwg.org#concept-fetch) | |||
| pub fn fetch(request: Rc<Request>) -> Response { | |||
| fetch_with_cors_cache(request, &mut BasicCORSCache::new()) | |||
This comment has been minimized.
This comment has been minimized.
KiChjang
Apr 27, 2016
Member
This is not behaviour documented in the fetch spec. @jdm does this look ok?
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| fetch_with_cors_cache(request, &mut BasicCORSCache::new()) | ||
| } | ||
|
|
||
| pub fn fetch_with_cors_cache<C: CORSCache>(request: Rc<Request>, cache: &mut C) -> Response { |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
dlrobertson
Apr 27, 2016
•
Author
Contributor
CORSCache is a trait, so you'll get the following error.
error: the trait bound `<trait>: std::marker::Sized` is not satisfied
I couldn't think of another way around it
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."
Remove the CORSCache trait, CORSCacheSender, CORSCacheThreadMsg, and CORSCacheThread. Rename BasicCORSCache to CORSCache and keep its old implementation of CORSCache.
| @@ -74,51 +73,20 @@ pub struct CacheRequestDetails { | |||
| pub credentials: bool | |||
This comment has been minimized.
This comment has been minimized.
KiChjang
Apr 28, 2016
Member
I'm wondering whether we even need this CacheRequestDetails struct at all... it feels like we can just do away this altogether and use Request instead. I think I'll file a follow-up issue to remove this.
This comment has been minimized.
This comment has been minimized.
|
@bors-servo r+ Thanks! |
|
|
1 similar comment
|
|
Fix logic for cors cache match 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 <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/10867) <!-- Reviewable:end -->
|
|
dlrobertson commentedApr 27, 2016
•
edited by larsbergstrom
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::credentialsis set to true if credentials mode is "include", and false otherwise. So(!cors_cache.credentials && !cors_req.credentials) || cors_cache.credentialswould be directly following the spec, but unless I'm mistakencors_cache.credentials || !cors_req.credentialsis logically the same.Fixes: #10525
This change is