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

Origin checks break count.html in Ten minute tutorial via file:// #75

Closed
claremacrae opened this issue Jul 15, 2014 · 5 comments
Closed

Comments

@claremacrae
Copy link

Summary

  • Expected behaviour: Load count.html from Ten minute tutorial via file://, and get the count displayed
  • Actual behaviour: Blank page, with rejected null origin in websocketd console.

From reading #20 comments and https://github.com/joewalnes/websocketd/blob/master/help.go, I expected the origin check to be disabled by default.

Detail

I'm working through the Ten minute tutorial.

I've created and tested count.py, and am running it via

websocketd-0.2.9-windows_amd64\websocketd.exe --port 8080 --devconsole python count.py

The test of loading via http://localhost:8080/ works.

However, when I create count.html, copied directly from the tutorial, I get a blank page. (JavaScript is not disabled)

The console output from websocketd says:

Tue, 15 Jul 2014 21:04:59 +0100 | ACCESS | session    | url:'http://localhost:80
80/' id:'1405454699281408400' remote:'PCBlah' command:'C:\Python27\python.exe'
 | rejected null origin
@claremacrae
Copy link
Author

As a separate test, I copied count.html to an existing Apache install, and viewed it via http://localhost:8800/count.html - and it worked fine.

So the problem really does appear to be only access via file://

@asergeyev
Copy link
Collaborator

Thanks! I don't know how I missed it, going to check/fix this shortly.

@asergeyev
Copy link
Collaborator

This code should solve your problem, thanks again!

@claremacrae
Copy link
Author

@asergeyev Thanks very much for doing this.

I had a go at building the latest code to test this, and ended up creating #76 instead.

@claremacrae
Copy link
Author

@asergeyev I've now been able to test the latest - and commit 0d22926 does indeed fix the problem, so think that this can be closed. Thank you!

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

No branches or pull requests

2 participants