Closed domenic closed 6 years ago
domenic
commented
6 years ago This may also help with https://github.com/whatwg/html/issues/1431 since HTML passes in the entry settings object as the client, but I can't currently find any observable way to distinguish that from a more sensible choice like current settings object. I'm not too well-versed in how the choice of client impacts things apart from referrer and Origin header, though...
tyoshino
commented
6 years ago IIRC, up to now, we haven't received any request from developers to send a referrer.
At least, WebKit (and therefore Blink) has implemented it from scratch than reusing the existing HTTP stack and didn't add anything more than what's specified in RFC 6455. Later, we added Cache-Control, etc. in response to some analysis, interop bug, user requests, but referrer wasn't.
As WebSockets are specified to always send the origin, it's ok to send a referrer including only the origin (though it's not useful as there's also the Origin header), but sending a full referrer would be a new addition to the web platform which developers may not expect.
So, my gut feeling is that we shouldn't make any change without users' voice but make the spec aligned with the browsers' current behavior.
domenic
commented
6 years ago Yeah, sorry for being unclear; I consider this a spec bug, not an implementation bug :). I just was hoping you'd have some helpful history, and you did!
tyoshino
commented
6 years ago Yeah, no problem. I just gave it a thought focusing on what would be good for users after forgetting what we have now!
https://fetch.spec.whatwg.org/#concept-websocket-establish does not mention omitting the referrer, but e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5512 does not seem to send one, at least in Chrome, Edge, and Firefox.
/cc @ricea @tyoshino.