Bug 35571 - WebSocket bufferedAmount doesn't include framing overhead
Summary: WebSocket bufferedAmount doesn't include framing overhead
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore JavaScript (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Fumitoshi Ukai
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-02 03:08 PST by Fumitoshi Ukai
Modified: 2013-04-08 23:03 PDT (History)
3 users (show)

See Also:


Attachments
Patch (4.65 KB, patch)
2010-03-02 20:53 PST, Fumitoshi Ukai
no flags Details | Formatted Diff | Diff
Patch (10.32 KB, patch)
2010-03-05 02:15 PST, Fumitoshi Ukai
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Fumitoshi Ukai 2010-03-02 03:08:27 PST
WebSocket spec draft says WebSocket bufferedAmount doesn't include framing overhead incurred by the protocol.
http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/003971.html
Comment 1 Fumitoshi Ukai 2010-03-02 20:53:56 PST
Created attachment 49876 [details]
Patch
Comment 2 Alexey Proskuryakov 2010-03-03 14:20:14 PST
Comment on attachment 49876 [details]
Patch

Isn't 0x00 allowed to be inside of message text? 0xff can never occur in UTF-8, but 0x00 can be there.

It seems that if bufferedAmount() is going to parse the buffer, then it should have a state machine, and also ASSERT that it knows about the current frame type. I don't know how to reasonably implement that, since the buffer won't necessarily start on frame boundary.

But also, this seems quite slow, perhaps it would be better to store data size separately (again, it can be a challenge to update properly). Or even to try and get the spec changed back per implementor feedback.

Do we have a test checking how null characters go over WebSocket?
Comment 3 Fumitoshi Ukai 2010-03-03 18:41:34 PST
(In reply to comment #2)
> (From update of attachment 49876 [details])
> Isn't 0x00 allowed to be inside of message text? 0xff can never occur in UTF-8,
> but 0x00 can be there.

Oh, i missed that case.

> It seems that if bufferedAmount() is going to parse the buffer, then it should
> have a state machine, and also ASSERT that it knows about the current frame
> type. I don't know how to reasonably implement that, since the buffer won't
> necessarily start on frame boundary.
> 
> But also, this seems quite slow, perhaps it would be better to store data size
> separately (again, it can be a challenge to update properly). Or even to try
> and get the spec changed back per implementor feedback.

Yes, I prefer previous spec.  I'll ask the spec changed back.

> Do we have a test checking how null characters go over WebSocket?

Not yet.
I'll add.
Comment 4 Fumitoshi Ukai 2010-03-05 02:15:02 PST
Created attachment 50093 [details]
Patch
Comment 5 Alexey Proskuryakov 2010-03-05 12:25:57 PST
I'm not sure if we want to make this change even if we can't get the spec changed back.
Comment 6 Alexey Proskuryakov 2010-03-29 14:48:41 PDT
Comment on attachment 50093 [details]
Patch

This doesn't currently need review, removing the flag. The behavior of bufferedAmount is still being actively discussed on whatwg mailing list.
Comment 7 Takeshi Yoshino 2013-04-08 23:03:20 PDT
The patch is obsolete (for Hixie 75 style framing).

Needs discussion on the spec. Maybe reopening https://www.w3.org/Bugs/Public/show_bug.cgi?id=9083 if necessary.

Marking this bug as WONTFIX for now.