Re: [whatwg/fetch] Block subresource requests whose URLs include credentials. (#465)

I guess I'm a little confused as to what the road block is then. So I'm going to write out what I think is going on, maybe you can steer me in the right direction.

Let's say I have a page requested at `http://user:pass@same.domain/` with the following html:
```html
<html>
 <head>
   <link rel="stylesheet" href="/a.css">
   <link rel="stylesheet" href="http://user:pass@other.domain/b.css">
   <link rel="stylesheet" href="http://user2:pass2@same.domain/c.css">
   <script>
     // JS code that adds some a link to a style sheet
     addStyleLink('/d.css');
     addStyleLink('http:/user:pass@other.domain/e.css');
     addStyleLink('http://user2:pass2@same.domain/f.css');
   </script>
 </head>
....
```

Under the proposed rule "Block subresource requests whose URLs include credentials", I think the following would happen: 
1. `a.css` would be requested with `user:pass` creds - this is currently broken in chrome?
2. `b.css` would not use creds to make the request, this is now blocked?
3. `c.css` should be requested with `user2:pass2` as the creds - or is this blocked?
4. `d.css` will be requested with `user:pass` creds
5. `e.css` request is blocked
6. `f.css` request is made with `user2:pass2` creds

Not sure how this should all play out in what should/should not be blocked from happening.

I'd prefer, and I think you'd step on a lot less peoples toes, if you just notified people they are doing something wrong, or it's a bad practice. At the end of the day, I think you'd get the results you want(steering people away from this practice), but not block peoples legitimate use(in their eyes) of this feature of the URL spec.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/465#issuecomment-313699927

Received on Friday, 7 July 2017 14:36:42 UTC