Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebSocket connections don't appear to send referrers #630

Closed
domenic opened this issue Nov 15, 2017 · 4 comments
Closed

WebSocket connections don't appear to send referrers #630

domenic opened this issue Nov 15, 2017 · 4 comments

Comments

@domenic
Copy link
Member

domenic commented Nov 15, 2017

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.

@domenic
Copy link
Member Author

domenic commented Nov 15, 2017

This may also help with whatwg/html#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
Copy link
Member

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
Copy link
Member Author

domenic commented Nov 15, 2017

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
Copy link
Member

tyoshino commented Nov 15, 2017

Yeah, no problem. I just gave it a thought focusing on what would be good for users after forgetting what we have now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants