search

ghedipunk / PHP-Websockets

A Websockets server written in PHP.
BSD 3-Clause "New" or "Revised" License
913 stars 376 forks source link

Latest Safari - WebSocket #13

Closed JAKgit closed 9 years ago

JAKgit commented 9 years ago

Hi,

First, great work and thank you for sharing! With the latest Safari 7.0.6 I still can't open a websocket connection, can you confirm?

Thanks Jérôme

blondie101010 commented 9 years ago

The README file does mention that Safari's stable release is not supported because of security issues.

JAKgit commented 9 years ago

Yes, I know.

Just wondering because since Safari 6 the protocol RFC-6455 is supported.

As from your other ticket, I tested here with Safari and it works fine: http://www.websocket.org/echo.html

JAKgit commented 9 years ago

Ok, I have found the issue.

When I use ws://www.mydomain it does not work in safari but in all others, but if I use ws://mydomain.com it works in all browsers.

blondie101010 commented 9 years ago

I'm sorry to say that is a bug on your part to wishfully expect the browser to autodetect the domain extension which is most unreliable.

This was done for end-users that didn't know how to search for the proper address. When you know the address, especially when you're a programmer, you should never leave the system guess what you want to do.

In the circumstances, I think this bug should get closed, unless you have more questions about it or more details to add.

ghedipunk commented 9 years ago

Based on the current implementation, it seems like the issue is your domain's DNS settings not having an A record or CNAME record for www.yourdomain.tld.

Without knowing your domain, of course, we can't confirm. Either way, DNS settings and browser assumptions are outside of the scope of a Websockets project. (Though admittedly, browser assumptions are frighteningly close to in scope.)

If your DNS settings are correct, your client is pulling the correct IP address of your server, and your client is sending anything in its Host header, then we should investigate further.

Still, it does bring up a point, and allude to a feature that I've been contemplating, so further discussion follows:

The reason why the Host header was added to HTTP 1.1 was to differentiate between different sites using the same browser. RFC 6455 states that the client must send a Host header in the opening handshake, but does not specify the server's responsibility in handling that header.

Following the example of web servers that use virtual hosts to serve up domain specific content, there should be a feature to run multiple WS applications on the same IP address, and for those applications to be specified by both the request URI and by the host... i.e., ws://example1.com/ws should be able to serve up a different application from ws://example2.com/ws.

The ability for a software developer to implement this exists, by overriding the checkHost() method of the WebSocketServer class, setting the host as a property of the client's connection, and checking that property when routing network events. I feel that this behavior should be more specifically implemented, though.

Development branch coming soon*, with the new branch having sweeping and breaking changes. (I'll be focusing more on interfaces than inheritance in the new version.)

*Definition of "soon": when my 3 month old twins let me. In other words, the twins might not be 3 months old any more by the time I'm able to start a new major version.

JAKgit commented 9 years ago

Thank you for the information, I will try some more scenarios, so far I can say that my DNS settings are correct on my server.

I never wrote it is a bug in the class just want to know what is going on, now I found the problem I have to check it further why it does that on Safari and not on Chrome or Firefox.

Kind regards Jérôme

ghedipunk commented 9 years ago

No activity on issue for over a month -- Closing under the assumption that there is no more to be done. (Feel free to reopen if necessary).