Closed Bug 679092 Opened 9 years ago Closed 9 years ago

WebSocket is closed after server returns handshake (ietf v7)

Categories

(Core :: Networking: WebSockets, defect)

6 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: knocte, Unassigned)

References

Details

Attachments

(6 files)

As per bug 640003 comment 96 I am creating this new bug.

Full logs are here: http://pastebin.com/A7MWSrF2

Sorry, cannot provide public IP with port open to test at the moment (but you can build it yourself applying to gtk3.1.x the patch in here: https://bugzilla.gnome.org/show_bug.cgi?id=656521

Thanks
Component: General → Networking: WebSockets
Product: Firefox → Core
QA Contact: general → networking.websockets
-259511440[823c748]: nsHttpConnection::PushBack [this=99a8f20, length=36]

This line indicates that there is server data immediately following the 101 response. There should not be any data there because the server in this application does not write first.

(03:53:15 PM) mcmanus: is the server supposed to send the first websockets message?
(03:53:47 PM) knocte2: nope

The first time websockets reads from the input, it sees garbage (fragmented opcode 13) and aborts..

-259511440[823c748]: WebSocketHandler::ProcessInput 8396fa8 [36 0]
-259511440[823c748]: WebSocketHandler:: ProcessInput payload 10 avail 34
-259511440[823c748]: WebSocketHandler::ProcessInput Frame accumulated - opcode 13
-259511440[823c748]: WebSocketHandler:: fragmented control frame code 13
-259511440[823c748]: WebSocketHandler::AbortSession() 8396fa8 [reason 80070057] stopped = 0

There is some non-websockets protocol data being sent from the server after the handshake completion.

I chatted with the reproter on irc - we identified the first 2 bytes are extra \r\n, the other 34 aren't known yet. Its probably an http response body (or whole other response?). He'll attach a pcap if problems persist, but this doesn't seem to be a firefox issue.
Status: NEW → RESOLVED
Closed: 9 years ago
Depends on: 640003
Resolution: --- → INVALID
Sorry I've been busy...

(In reply to Patrick McManus from comment #1)
> (03:53:15 PM) mcmanus: is the server supposed to send the first websockets
> message?
> (03:53:47 PM) knocte2: nope

What if I was wrong when I answered this? I haven't had time to look at this properly through wireshark yet, but what if the server was the one sending messages before than the client?(just after giving the handshake response)

Does the RFC mention that the user-agent should drop the connection in this case? If not, why did Firefox 6 change the behaviour compared to v5?
(In reply to Andrés G. Aragoneses from comment #2)
 
> What if I was wrong when I answered this? 

The you will have invalidated the log analysis work I did for you :)

> I haven't had time to look at this
> properly through wireshark yet, but what if the server was the one sending
> messages before than the client?(just after giving the handshake response)

There is nothing wrong with that as long as they are legit websockets protocol bytes.. That's why I asked the question (i.e. if you tell me that the server didn't send first we know for sure they are junk - if it did send first then they are of unknown validity.. But we know for certain that the first 2 bytes are crap (and the session is being aborted based upon them), and I posited based on your reply that the other 34 are crap too. Perhaps they are not if you have changed your mind about the question.

> Does the RFC mention that the user-agent should drop the connection in this
> case?

The connection is being dropped based on the garbage in the first two bytes. I don't know what is in the next 34, so I can't tell you what would happen with them. It is not being dropped because the server sent the first message.
Thanks for your clarifications. More info below:


(In reply to Patrick McManus from comment #3)
> (In reply to Andrés G. Aragoneses from comment #2)
>  
> > What if I was wrong when I answered this? 
> 
> Then you will have invalidated the log analysis work I did for you :)
> 
> > I haven't had time to look at this
> > properly through wireshark yet, but what if the server was the one sending
> > messages before than the client?(just after giving the handshake response)
> 
> There is nothing wrong with that as long as they are legit websockets
> protocol bytes.. That's why I asked the question (i.e. if you tell me that
> the server didn't send first we know for sure they are junk - if it did send
> first then they are of unknown validity.. But we know for certain that the
> first 2 bytes are crap (and the session is being aborted based upon them),
> and I posited based on your reply that the other 34 are crap too. Perhaps
> they are not if you have changed your mind about the question.

So I've finally tested this with wireshark, and I have confirmed that the server sends the first data (so I guess those are the 34 bytes).

I've compared the traces with wireshark between Firefox4 (working) and Firefox6, and the extra "\r\n" I send from the server (which we were suspecting to be part of those "bad" 34 bytes) after the last Sec-WebSocket-Accept line are actually correct,


> > Does the RFC mention that the user-agent should drop the connection in this
> > case?
> 
> The connection is being dropped based on the garbage in the first two bytes.
> I don't know what is in the next 34, so I can't tell you what would happen
> with them. It is not being dropped because the server sent the first message.

Hopefully with the info above and the screenshots I'm going to add now to this bug we can shed some light?
(In reply to Andrés G. Aragoneses from comment #4)
> ...
> suspecting to be part of those "bad" 34 bytes) after the last
> Sec-WebSocket-Accept line are actually correct,

I meant to finish this with "because they are also there in the Firefox v4 handshake". Look at the screenshots please, and tell me what you think? (Not sure how to capture this properly with text instead of screenshots yet sorry, I'll look more deeply into wireshark docs.)
Andres,

The firefox 4 captures are 100% irrelevant to this issue. Firefox 4 and 6 speak different protocols, whatever ff4 may or may not do is not germane to ff6. Websockets has never been shipped on-by-default before Firefox 6 and I won't spend time investigating an old implementation that was rewritten for firefox 6. Please do not confuse the issue by comparing ff4 and ff6.

But make no mistake: I'm happy to help you with ff >= 6 and I'm glad you're using websockets!

Am I to understand you are still having trouble getting FF6 to operate with your Websockets server and you believe that is a firefox bug?

If I have that correct, Please provide the packet capture of a failed session that you have in "pcap" format - you will find that under the save as menu of wireshark. The screen captures hardly scratch the surface. Please also describe in detail where you think firefox is in error.

If you provide that information I should be able to confirm whether or not there is a problem on firefox's side.

Thanks,
Pat
(In reply to Patrick McManus from comment #10)
> Andres,
> 
> The firefox 4 captures are 100% irrelevant to this issue. Firefox 4 and 6
> speak different protocols, whatever ff4 may or may not do is not germane to
> ff6. Websockets has never been shipped on-by-default before Firefox 6 and I
> won't spend time investigating an old implementation that was rewritten for
> firefox 6. Please do not confuse the issue by comparing ff4 and ff6.

AFAIU the main differences between the versions shipped of the protocol comparing FF4 and FF6 is the handshake, but the fact that the server can start the connection should remain equal, that's the only reason I mention FF4 here.


> But make no mistake: I'm happy to help you with ff >= 6 and I'm glad you're
> using websockets!
> 
> Am I to understand you are still having trouble getting FF6 to operate with
> your Websockets server and you believe that is a firefox bug?
> 
> If I have that correct, Please provide the packet capture of a failed
> session that you have in "pcap" format - you will find that under the save
> as menu of wireshark. The screen captures hardly scratch the surface. Please
> also describe in detail where you think firefox is in error.
> 
> If you provide that information I should be able to confirm whether or not
> there is a problem on firefox's side.
> 
> Thanks,
> Pat

Great! I'll provide that ASAP. Thank you Pat.
(In reply to Andrés G. Aragoneses from comment #11)

> AFAIU the main differences between the versions shipped of the protocol
> comparing FF4 and FF6is the handshake, 

I don't agree with that. The two protocols are not similar at all.

> but the fact that the server can
> start the connection should remain equal, 

that is true and FF6 has no problem at all with the server speaking websockets first. I'm sorry if I left you with that impression. I asked you the question of whether or not your server was intending to speak first in order to help interpret your log. Your answer informed my log analysis, but I never said the server was either required or prohibited from speaking first in the general case. There is no ordering required by the websocket protocol after the handshake is complete nor is an ordering enforced by firefox.
Hi again Patrick, sorry for the delay.

(In reply to Patrick McManus from comment #12)
> (In reply to Andrés G. Aragoneses from comment #11)
> 
> > AFAIU the main differences between the versions shipped of the protocol
> > comparing FF4 and FF6is the handshake, 
> 
> I don't agree with that. The two protocols are not similar at all.

Ok, from my brief reading about the protocol I came to a wrong conclusion then.


> 
> > but the fact that the server can
> > start the connection should remain equal, 
> 
> that is true and FF6 has no problem at all with the server speaking
> websockets first. I'm sorry if I left you with that impression. I asked you
> the question of whether or not your server was intending to speak first in
> order to help interpret your log. Your answer informed my log analysis, but
> I never said the server was either required or prohibited from speaking
> first in the general case. There is no ordering required by the websocket
> protocol after the handshake is complete nor is an ordering enforced by
> firefox.

Cool, I'm going to attach plain/text files of what wireshark captured, I hope it's enough.
(In reply to Andrés G. Aragoneses from comment #13)

> Cool, I'm going to attach plain/text files of what wireshark captured, I
> hope it's enough.

Hi Andres, I appreciate the logfile for FF6. If you need to do this again please use the pcap format not the text one - it saves me tons of time to use the pcap format directly and therefore I'll be able to get back to you more efficiently.

However I was able to find the leading problem with your server implementation based on the trace file you did provide.

Frame 38 contains the HTTP server response with the correct 101 level response code. The complete response is in this frame, including the blank line (just a CRLF without a name:value pair) that delimits the HTTP response from the websockets data that will follow. Bytes that follow after this will need to adhere to the websocket protocol definition.

Frame 39 is just an ack frame without any data.

Frame 40 contains the first websocket bytes - they are from the server to the client. It is actually just a single byte: 00. The first byte of 00 in a frame decodes to "no flags set and opcode = 0". 

Opcode of 0 is the continuation opcode - it is only valid as part of a fragment sequence of multiple frames that comprise a single message. It is used to flag the "continued frames", by definition the first frame is never a continuation frame.

Therefore you have generated invalid websockets protocol data from your server.
(In reply to Patrick McManus from comment #16)
> Hi Andres, I appreciate the logfile for FF6. If you need to do this again
> please use the pcap format not the text one - it saves me tons of time to
> use the pcap format directly and therefore I'll be able to get back to you
> more efficiently.

So sorry. Don't know why I didn't realise there were more formats to choose when exporting!

(I also realised that I should have compressed the file because it's too big :-( Although maybe Bugzilla should automatically compress it on the DB; note to self: file an enh request on bugzilla's product.)


> However I was able to find the leading problem with your server
> implementation based on the trace file you did provide.
> 
> Frame 38 contains the HTTP server response with the correct 101 level
> response code. The complete response is in this frame, including the blank
> line (just a CRLF without a name:value pair) that delimits the HTTP response
> from the websockets data that will follow. Bytes that follow after this will
> need to adhere to the websocket protocol definition.
> 
> Frame 39 is just an ack frame without any data.
> 
> Frame 40 contains the first websocket bytes - they are from the server to
> the client. It is actually just a single byte: 00. The first byte of 00 in a
> frame decodes to "no flags set and opcode = 0". 
> 
> Opcode of 0 is the continuation opcode - it is only valid as part of a
> fragment sequence of multiple frames that comprise a single message. It is
> used to flag the "continued frames", by definition the first frame is never
> a continuation frame.

Ah, great! What should I send instead then?
> 
> Ah, great! What should I send instead then?

From MDN: WebSockets support in Firefox is continuing to track the evolving WebSocket specification. Firefox 6 implements version 7 of the underlying protocol, while Firefox 7 implements version 8 (as specified by IETF draft 10). Firefox mobile received WebSocket support in Firefox mobile 7.0.

You can find version 7 documentation at http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07
You need to log in before you can comment on or make changes to this bug.