Bug 54811

Summary: REGRESSION(r78383): Failure to connect on websocketstest.com
Product: WebKit Reporter: Alexey Proskuryakov <ap>
Component: Page LoadingAssignee: Yuta Kitamura <yutak>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, eric, ukai, yutak
Priority: P1 Keywords: InRadar, Regression
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.6   
URL: http://websocketstest.com/
Attachments:
Description Flags
Patch darin: review+

Alexey Proskuryakov
Reported 2011-02-19 11:44:47 PST
According <http://websocketstest.com/>, connecting on port 80 is broken on ToT. It works with Safari 5.0.3
Attachments
Patch (3.48 KB, patch)
2011-02-28 20:23 PST, Yuta Kitamura
darin: review+
Alexey Proskuryakov
Comment 1 2011-02-19 11:45:27 PST
Yuta Kitamura
Comment 2 2011-02-25 05:43:13 PST
It seems like CFSocket reports EADDRNOTAVAIL. Unfortunately there was no useful infomation left in the stack and I could not see what was happening under CF. I will try bisect...
Yuta Kitamura
Comment 3 2011-02-28 02:33:00 PST
I did bisect this regression and found that the revision caused this regression is r78383. http://trac.webkit.org/changeset/78383 SocketStreamHandle for CF (WebCore/platform/network/SocketStreamHandleCFNet.cpp) calls KURL::setPort() in its constructor (line 73) and tries to make sure the port number (":80" or ":443") is always included in the host part. After r78383, KURL::setPort() no longer appends the port part if you specify the default port number for a given scheme. That's why SocketStreamHandle has regressed. I'm not sure if the current usage of setPort() in SocketStreamHandle is valid or not. I'd like to hear Eric and Adam's opinion about this. If SocketStreamHandle needs a fix, I think I can do it.
Yuta Kitamura
Comment 4 2011-02-28 20:23:11 PST
Yuta Kitamura
Comment 5 2011-02-28 21:19:38 PST
This patch is an attempt to fix SocketStreamHandleCFNet so that it does not rely on KURL::setPort() appending ":port" part. This regression makes us unable to connect to almost all WebSocket servers (listening at the default port), which sounds rather serious to me.
Fumitoshi Ukai
Comment 6 2011-02-28 21:53:54 PST
Comment on attachment 84183 [details] Patch LGTM
Alexey Proskuryakov
Comment 7 2011-02-28 22:37:08 PST
Another possible fix would be to remove WebSocket ports from KURL default list. Eric, what do you think?
Eric Seidel (no email)
Comment 8 2011-02-28 23:51:24 PST
What does GKURL do in this case? I'm not familiar enough with KURL::port() but I wonder if it shouldn't know how to return the defualt ports.
Yuta Kitamura
Comment 10 2011-03-01 02:47:00 PST
KURL (after r78383) and KURLGoogle are aligned in terms of setPort() behavior. So, I think fixing SocketStreamHandleCFNet is sufficient...
Darin Adler
Comment 11 2011-03-01 09:57:07 PST
Comment on attachment 84183 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=84183&action=review I’m going to say r=me, but I’d prefer that the function name be changed. > Source/WebCore/platform/network/cf/SocketStreamHandle.h:75 > + unsigned short getPort() const; WebKit style naming for these functions does not include the word “get” -- this is mentioned in the Names section of <http://www.webkit.org/coding/coding-style.html>. This function should just be named port. The patch is otherwise fine.
Yuta Kitamura
Comment 12 2011-03-01 22:03:25 PST
Thanks, I will rename the function and commit manually.
Yuta Kitamura
Comment 13 2011-03-01 22:06:25 PST
Note You need to log in before you can comment on or make changes to this bug.