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

Websockets don't load with capitalized server names #100

Closed
rianadon opened this issue May 6, 2016 · 5 comments
Closed

Websockets don't load with capitalized server names #100

rianadon opened this issue May 6, 2016 · 5 comments

Comments

@rianadon
Copy link

rianadon commented May 6, 2016

This time this shouldn't be related to a Windows Insiders build 😀 .

I finally have hotel working by fiddling with the source code a little to suit the weird Windows-related bug, but the websockets on a page I'm proxying don't work when I capitalize the name of a server (but the page still loads).

Otherwise, if the name (which I specify through hotel add ... -n ...) is lowercase, the websockets work fine.

Looking at the code, the error seems to be in app.js when the server checks to see if the origin is valid. If the name is capitalized, the server id is also capitalized, but the id variable (from the origin) is lowercase and therefore does not match, causing servers.has(id) to return false.

Thanks!

@rianadon
Copy link
Author

Hi!

It's been a little over a week with no response, so I'm just curious what the progress of this is, or if there is even a plan to make non-lowercase server names supported (which in that case you may want to add a warning). Thank you!

@rianadon rianadon changed the title Websockets not working with capitalized names Websockets don't load with capitalized server names May 13, 2016
@typicode
Copy link
Owner

Sorry for that, thanks for reminding about this. When switching between projects I sometime forget about some issues that I wanted to reply to.

Actually, My Project_Name$ hotel add ... is automatically converted to a valid domain my-project-name. I didn't apply this logic when -n is passed so that users can force whatever name or syntax they want.

For example, _ is accepted in a domain name. It's not valid but it'll work in most browsers. So -n lets do that.

Also, capitalized letter can be used in URL paths. For example http://localhost:2000/MyProject is valid.

So all in all, that's why I didn't felt converting automatically name passed using -n. Maybe as you suggested a warning about potential issues could be useful.

@rianadon
Copy link
Author

That's fine. I understand how you could be so busy with so many repositories.

A warning or even a note in the README would be appreciated as I didn't know about this beforehand.

@typicode
Copy link
Owner

Name will now automatically be converted to a valid domain to prevent such cases.
Thanks again for the feedback :)

@rianadon
Copy link
Author

You are very welcome :)

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