[Webkit-unassigned] [Bug 199189] WebSockets: add support for sending blob messages when using web sockets platform APIs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=199189

youenn fablet <youennf at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #373095|review?                     |review+
              Flags|                            |

--- Comment #12 from youenn fablet <youennf at gmail.com> ---
Comment on attachment 373095
  --> https://bugs.webkit.org/attachment.cgi?id=373095
Try to fix apple builds

r=me.

Since we might want the same mechanism for DataChannel, I wonder though whether we should not have a more generic mechanism.
Something like a Queue where we can push String/ArrayBuffer/Blob.
The queue could be query whether empty or not.
It would take a Function callback to notify that a Variant<String, ArrayBuffer> is ready to be sent.

View in context: https://bugs.webkit.org/attachment.cgi?id=373095&action=review

> Source/WebKit/WebProcess/Network/WebSocketChannel.cpp:253
> +

As per spec, I think we should increase the buffered amount by blob.size() synchronously.
And decrement it when receiving the IPC message.
This does not seem to be like this in the previous implementation though.
It might be nice to have a test for that and check what other browsers are doing.

> Source/WebKit/WebProcess/Network/WebSocketChannel.cpp:264
> +                sendMessage(Messages::NetworkSocketChannel::SendData { IPC::DataReference { reinterpret_cast<const uint8_t*>(binaryData.data()), binaryData.size() } }, binaryData.size());

Maybe we should have routines for these sendMessage(text) sendMessage(binary).

> Source/WebKit/WebProcess/Network/WebSocketChannel.cpp:277
> +                    fail(makeString("Failed to load Blob: error code = ", errorCode.value()));

I am not sure this error handling is good enough.
If there is no test coverage for that case, we should file a bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190628/39474d6b/attachment.html>