web cam websocket

[Mikhail]

Hi,

I'm try simple web camera app (attached here script). That works fine with Firefox browser but Chrome did not works and show the error:

WebSocket connection to 'ws://localhost:3000/feed?feed=%2Ffeed%2Fcam1' failed: Error during WebSocket handshake: Sent non-empty 'Sec-WebSocket-Protocol' header but no response was received

and log:

• [2020-09-14 16:50:19.43834] [5345] [info] [G4k6PIcS] Client connected: Mojolicious::Controller=HASH(0x3576860); to feed: Mojo::IOLoop::Stream=HASH(0x3510830); clients: 3
• [2020-09-14 16:50:19.43859] [5345] [debug] [G4k6PIcS] 101 Switching Protocols (0.001538s, 650.195/s)
• [2020-09-14 16:50:19.44027] [5345] [info] [G4k6PIcS] Client disconnected: Mojolicious::Controller=HASH(0x3576860); clients: 2

==========================

CORE
  Perl        (v5.26.1, linux)
  Mojolicious (8.59, Supervillain)

OPTIONAL
  Cpanel::JSON::XS 4.09+   (n/a)
  EV 4.32+                 (n/a)
  IO::Socket::Socks 0.64+  (n/a)
  IO::Socket::SSL 2.009+   (2.066)
  Net::DNS::Native 0.15+   (n/a)
  Role::Tiny 2.000001+     (2.000008)
  Future::AsyncAwait 0.36+ (n/a)

=========================

Regards.

[Sebastian Riedel]

Then you need to negotiate a subprotocol.

--

sebastian

[Mikhail]

Thanks! Forever ♥ Mojolicious!

понедельник, 14 сентября 2020 г. в 13:41:46 UTC+5, Sebastian Riedel:

[Felipe Gasper]

That seems an odd error from Chrome, if that’s the fix .. was the browser sending a subprotocol in the handshake?

-F

On Sep 14, 2020, at 07:37, Mikhail <m.nas...@gmail.com> wrote:

Thanks! Forever ♥ Mojolicious!

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mojolicious/68624663-2baf-4bc2-a24e-b8fc135ff15dn%40googlegroups.com.

[Mikhail]

Chrome browser  absolutely described the error in that it sent a subprotocol header ('null' for that case). So solve

$ws->tx->with_protocols('binary', 'null');

Let binary subprotocol is present also.

понедельник, 14 сентября 2020 г. в 17:29:31 UTC+5, fel...@felipegasper.com:

[Felipe Gasper]

RFC 6455/1.9 states:

The client can request that the server use a specific subprotocol by
   including the |Sec-WebSocket-Protocol| field in its handshake.  If it
   is specified, the server needs to include the same field and one of
   the selected subprotocol values in its response for the connection to
   be established.

Given this, should Mojo even send a response? Or if it does, should it at least warn “failed to negotiate subprotocol; sending handshake response anyway”?

-FG

On Sep 15, 2020, at 04:21, Mikhail <m.nas...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/mojolicious/e4166da1-91ce-40e3-810b-2511725ad8b1n%40googlegroups.com.

[Sebastian Riedel]

Given this, should Mojo even send a response? Or if it does, should it at least warn “failed to negotiate subprotocol; sending handshake response anyway”?

 So you want Mojolicious to cause a TCP level connection error instead of letting the handshake fail properly? That seems like a really bad idea.

[Felipe Gasper]

> On Sep 15, 2020, at 9:30 AM, Sebastian Riedel <kra...@gmail.com> wrote:
>
> Given this, should Mojo even send a response? Or if it does, should it at least warn “failed to negotiate subprotocol; sending handshake response anyway”?
>
> So you want Mojolicious to cause a TCP level connection error instead of letting the handshake fail properly? That seems like a really bad idea.

An HTTP-level error response--maybe 426--would probably be most sensible.

-FG

[Sebastian Riedel]

An HTTP-level error response--maybe 426--would probably be most sensible.

What error would common browsers give in that case? 

--

Sebastian

[Felipe Gasper]

> On Sep 15, 2020, at 11:20 AM, Sebastian Riedel <kra...@gmail.com> wrote:
>
> An HTTP-level error response--maybe 426--would probably be most sensible.
>
> What error would common browsers give in that case?

They’d give whatever error as with any other HTTP-level failure during a WS handshake.

Chrome shows a console error with the response code. A 404, for example, yields:

----
Error during WebSocket handshake: Unexpected response code: 404
----

-FG