Closed Bug 675919 Opened 13 years ago Closed 13 years ago

Websockets - FAIL connection on recv of any unknown opcode

Categories

(Core :: Networking: HTTP, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla8

People

(Reporter: mcmanus, Assigned: mcmanus)

References

Details

(Whiteboard: [inbound])

Attachments

(1 file)

bug 664344 points out that we fail the connection on recv of unknown rsv bits, and unknown ctrl opcodes, but not other opcodes. Section 4.2 of ietf-10 makes it clear that fail is the right behavior.
Blocks: 664344
bug 664344 says "FF (correctly) closes a connection upon receiving reserved control frame opcodes, but not reserved data frame opcodes. The latter will just be silently ignored." and points to tests

Frame with reserved control frame opcode (3)[pass]
and
Frame with reserved data frame opcode (11)[fail]

I think you have those backwards. According to -10 
"%x3-7 are reserved for further non-control frames" and " %xB-F are reserved for further control frames". So it is actually the reserved control code (11) that is not failing the connection.

So the FF issue is that we don't fail on unknown control opcodes.

So we each have a bug :)
Attached patch patch 1Splinter Review
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Attachment #550074 - Flags: review?(jduell.mcbugs)
;) fair enough. btw: a chrome developer contacted me .. chrome 14 supports -10, which is good. especially, since I now can compare two major implementations and the spec. - rest assured: they also have bugs (others though) ;). Currently, I'm extending the stuff for full automation, so that I can run - not only browser - against a broad suite of test cases. I let you know when it's in some usable state.
Comment on attachment 550074 [details] [diff] [review]
patch 1

Review of attachment 550074 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/protocol/websocket/WebSocketChannel.cpp
@@ +991,5 @@
>          // opcode kPong: the mere act of receiving the packet is all we need
>          // to do for the pong to trigger the activity timers
>          LOG(("WebSocketChannel:: pong received\n"));
>        }
> +      else {

put else on same line, i.e. "} else {"
Attachment #550074 - Flags: review?(jduell.mcbugs) → review+
http://hg.mozilla.org/integration/mozilla-inbound/rev/cd0106ceb8ce
Whiteboard: [inbound]
Target Milestone: --- → mozilla8
http://hg.mozilla.org/mozilla-central/rev/cd0106ceb8ce
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: