GoDaddy Serves Blank Pages to Safari & Opera

zackmac writes "For over two weeks domain registrar GoDaddy has been serving blank pages to Safari and Opera users who attempt to access sites using its domain forwarding and masking service. GoDaddy is blaming Apple as the source of the problem, and with nowhere to turn, Mac users are flocking to Apple's support forums to discuss the issue in-depth. Apple has so far been unresponsive and GoDaddy has directed affected customers to contact Apple Support. An inconvienent workaround is to open the website first in Firefox or Internet Explorer and then the page will load in Safari or Opera. Speculation abounds as to the cause of the problem and how to fix it. The current belief is malformed headers, an invalid 302 header with a bogus location and a redirect loop."

Comments

goDaddy sucks

[dmf415]

goDaddy has horrible support. They banned my domain and claimed thousands of people were getting emails pointing to my site to capture ebay passwords. I had been using this auction add-on for ecommerce. To cut a long story short, I moved to yahoo which offers free dns forwarding!

Re:Godaddy sucks

[ihbphx]

I agree with that. I used to have a domain that I registered for two years with GoDaddy back in 2002.
At 2004, when the domain suppose to expire, I did not want to renew this domain, because it was for my ex-girlfriend. Besides the credit card that I used to register for this domain expired in 2003.

In August 2004, I noticed a charge to my credit card from GoDaddy. I argued that they did not have right to charge my credit card because:
1. The expiration date in their record is expired.
2. They never got any consent from me to auto renew the domain.

When I spoke with their customer service, the customer service managed to trick me to tell my new expiration date, and she subsequently changed the expiration information at their records, as I could see from their webpage.

I know I was stupid to be tricked like that, but I suppose this is not a company suppose to work.

FTFA

[Anonymous Coward]

Update: GoDaddy said that not all Safari are having difficulty accessing forwarded domain names and disclaimed responsibility for the problems; the company, however, indicated that the problem would be fixed, but gave no specific time frame: "we have determined the issue is NOT related to a glitch in our service, but rather with a product supplied by one of our vendors. We are actively working on resolving this issue and expect it to be fixed shortly."

Re:Can anyone confirm this?

[Carthag]

Works in Safari for me. Also I can't see anything strange in the headers. Safari 2.0.2 (416.12) on 10.4.3

Re:Can anyone confirm this?

[Wabbit Wabbit]

Interesting... it came up for me OK in Safari, BUT...I'm on 10.3.9, not 10.4.x so I'm using a different branch of WebKit/WebCore/WebWhatever (Safari version 1.3.1).

redirects from GoDaddy appear hosed

[jeavis]

Here's what it looks like when asking for one of the sites mentioned on the Apple boards:

% telnet www.catalogueofships.com 80
Trying 64.202.167.129...
Connected to catalogueofships.com.
Escape character is '^]'.
GET / HTTP/1.1
HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /?ABCDEFGH
Connection closed by foreign host.

Notice that I specified HTTP/1.1, but it never even gave me a chance to specify a host header. The 302 came almost immediately after I hit Enter on the GET line. I can't see how that could possibly be a Safari or Opera problem.

Re:Can anyone confirm this?

[larry bagina]

ok, I had ethereal log everything while I connected via firefox. FF received the same 2 circular redirects, but the third time (requesting / again) it received the actual data for the page.

Re:Can anyone confirm this?

[morcheeba]

9 2.063551 10.1.1.113 -> 64.202.167.129 HTTP GET / HTTP/1.1
10 2.104156 64.202.167.129 -> 10.1.1.113 HTTP HTTP/1.1 302 Moved Temporarily

Frame 9 (312 bytes on wire, 312 bytes captured)
Arrival Time: Dec 8, 2005 17:20:12.255431000
Time delta from previous packet: 0.000944000 seconds
Time relative to first packet: 2.063551000 seconds
Frame Number: 9
Packet Length: 312 bytes
Capture Length: 312 bytes
Ethernet II, Src: 00:0a:95:f1:d3:e8, Dst: 00:09:0f:87:3b:a6
Destination: 00:09:0f:87:3b:a6 (Fortinet_87:3b:a6)
Source: 00:0a:95:f1:d3:e8 (AppleCom_f1:d3:e8)
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.1.1.113 (10.1.1.113), Dst Addr: 64.202.167.129 (64.202.167.129)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 298
Identification: 0x2381 (9089)
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0x2290 (correct)
Source: 10.1.1.113 (10.1.1.113)
Destination: 64.202.167.129 (64.202.167.129)
Transmission Control Protocol, Src Port: 62721 (62721), Dst Port: http (80), Seq: 3475988893, Ack: 2316008146, Len: 246
Source port: 62721 (62721)
Destination port: http (80)
Sequence number: 3475988893
Next sequence number: 3475989139
Acknowledgement number: 2316008146
Header length: 32 bytes
Flags: 0x0018 (PSH, ACK)
Congestion Window Reduced (CWR): Not set
ECN-Echo: Not set
Urgent: Not set
Acknowledgment: Set
Push: Set
Reset: Not set
Syn: Not set
Fin: Not set
Window size: 65535
Checksum: 0x8bee (correct)
Options: (12 bytes)
NOP
NOP
Time stamp: tsval 2035949578, tsecr 2035949578
Hypertext Transfer Protocol
GET / HTTP/1.1\r\n
Request Method: GET
Accept: */*\r\n
Accept-Language: en\r\n
Accept-Encoding: gzip, deflate\r\n
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/416.12 (KHTML, like Gecko) Safari/416.13\r\n
Connection: keep-alive\r\n
Host: www.photosparks.com\r\n
\r\n

Frame 10 (127 bytes on wire, 127 bytes captured)
Arrival Time: Dec 8, 2005 17:20:12.296036000
Time delta from previous packet: 0.040605000 seconds
Time relative to first packet: 2.104156000 seconds
Frame Number: 10
Packet Length: 127 bytes
Capture Length: 127 bytes
Ethernet II, Src: 00:09:0f:87:3b:a6, Dst: 00:0a:95:f1:d3:e8
Destination: 00:0a:95:f1:d3:e8 (AppleCom_f1:d3:e8)
Source: 00:09:0f:87:3b:a6 (Fortinet_87:3

Re:Can anyone confirm this?

[Chmarr]

Yeah, that's go-daddy's fault all right. The Location field is supposed to contain the FULL URL, not just a relative one.

Relative 302s violate the RFC

[Evro]

According to RFC 2616, Location: headers are supposed to be absolute URIs, not relative ones. I understand that it's a relatively common practice to do relative URIs on 302 redirects, but it's wrong. I don't know if this has anything to do with the Safari problem, though.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14. html#sec14.30

14.30 Location

The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI.

Location = "Location" ":" absoluteURI

An example is:

Location: http://www.w3.org/pub/WWW/People.html

            Note: The Content-Location header field (section 14.14) differs
            from Location in that the Content-Location identifies the original
            location of the entity enclosed in the request. It is therefore
            possible for a response to contain header fields for both Location
            and Content-Location. Also see section 13.10 for cache
            requirements of some methods.

GoDaddy's Fault

[jay2003]

GoDaddy's server is returning:

HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /?ABCDEFGH

This is a violation of RFC 2616. Section 14.30 specifies the Location header to contain an absolute URI:

The field value consists of a single absolute URI.
Location = "Location" ":" absoluteURI

Firefox is tolerant of the spec violation and Safari and Opera are apparently not. I spent many years writing HTTP proxies and after working around many broken clients and server, I have little sympathy for those who violate the spec and then whine that others should work around the problem. GoDaddy needs to fix their server. Accomodating their brokeness, just will encourage others to be sloppy as well.

Re:GoDaddy's Fault

[jay2003]

I looked at it some more, and Chuck, I think you are right that's it was more complicated. GoDaddy has apparently fixed the problem though, as the example page, www.photosparks.com now works with Safari When I first tried with telnet, I immediately got back a 302 after sending the request line. Now, telneting gets the correct response. I took a packet trace of Safari and it seems that Safari sends headers in such a way the headers can end up in multiple TCP packets. My guess is that GoDaddy's server was getting confused if the request did not come in one packet. This is a a common bad implementation practive where the code incorrectly assumes if it does a successful read on a new connection that it gets the complete header. So much for GoDaddy's whining that it was Apple's problem. The RFC is very clear that the header is not over until empty line is received. Each byte can come in its own packet and the server should be able to handle it.

Re:GoDaddy's Fault, not allowing client headers

[EMR]

Also Godaddy's servers are not allowing client headers to be sent.

Godaddy's servers IMMEDIATLY respond with the redirect not allowing the client to specify it's user agent, the host it's trying to access (http 1.1 spec) or any other headers. as it responds with the 302 reponse after ONE CR/LF instead of 2 CR/LF which is required by the HTTP specification..

This is CLEARLY Go Daddy incorrectly following the HTTP specification with their server.

Blaming apple??

[geniusj]

Wow.. I work for GoDaddy and I have heard nothing regarding us blaming Apple for this problem. I've heard plenty about us blaming another vendor (whom I can't name), but not Apple. Unfortunately, it's not a problem that can be fixed until this unnamed vendor provides a patch.

Re:Can anyone confirm this?

[Malc]

Bad URL. You're right though. So the web server is doing something that appears to be rather dumb. I suppose Opera and Safari are trying to be clever - maybe try to avoiding an infinite loop. I can't be arsed to go and look at the HTTP RFC to see what it says on this kind of thing. I suspect it says no caching, but the browsers are trying to protect themselves from a potentially bad situation (continual redirects).

Here's my Ethereal trace:

GET / HTTP/1.1
Host: www.photosparks.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Accept: text/xml,application/xml,application/xhtml+xml,tex t/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-gb,en-ca;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://apple.slashdot.org/article.pl?sid=05/12/08/ 236246&tid=177&tid=95

HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /?ABCDEFGH

GET /?ABCDEFGH HTTP/1.1
Host: www.photosparks.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Accept: text/xml,application/xml,application/xhtml+xml,tex t/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-gb,en-ca;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://apple.slashdot.org/article.pl?sid=05/12/08/ 236246&tid=177&tid=95

HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /

GET / HTTP/1.1
Host: www.photosparks.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Accept: text/xml,application/xml,application/xhtml+xml,tex t/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-gb,en-ca;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://apple.slashdot.org/article.pl?sid=05/12/08/ 236246&tid=177&tid=95

HTTP/1.1 200 OK
Date: Fri, 09 Dec 2005 00:42:58 GMT
Server: Apache/1.3.31 (Unix) mod_pointer/0.8 PHP/4.4.1
X-Powered-By: PHP/4.4.1
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

[...]

From the website....

[UncleRage]

GoDaddy.com learned that some customers using the Apple Safari web browser were having difficulty accessing forwarded domain names. At this time, we have determined the issue is NOT related to a glitch in our service, but rather with a product supplied by one of our vendors. We are actively working on resolving this issue and expect it to be fixed shortly.

It doesn't actually look as though GoDaddy is blaming Apple as much as simply not knowing what the actual culprit is. A small, but possibly important, difference.

That being said, I really hate their name. :|

Re:baseless zealotry

[Phroggy]

Statistics

Safari is the #3 most popular web browser behind Internet Explorer and Firefox, according to whoever these guys are. It's also the #1 browser on the #2 desktop OS. To ignore Safari is to embrace Microsoft's monopoly. Most of us here on Slashdot aren't particularly happy with that idea.

Re:Can anyone confirm this?

[dgatwood]

More than that, I'm not even seeing page source in Safari. In fact, I can't see how any browser would work. Here's a telnet session to port 80.

bash$ telnet www.photosparks.com 80
Trying 64.202.167.129...
Connected to photosparks.com.
Escape character is '^]'.
GET / http/1.1
HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /?ABCDEFGH
Connection closed by foreign host.

bash$ telnet www.photosparks.com 80
Trying 64.202.167.129...
Connected to photosparks.com.
Escape character is '^]'.
GET /?ABCDEFGH http/1.1
HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /
Connection closed by foreign host.

If I LIE to it and say http/1.0, it works:

bash$ telnet www.photosparks.com 80
Trying 64.202.167.129...
Connected to photosparks.com.
Escape character is '^]'.
GET / http/1.0
host: www.photosparks.com

HTTP/1.1 200 OK
Date: Fri, 09 Dec 2005 01:02:37 GMT
Server: Apache/1.3.31 (Unix) mod_pointer/0.8 PHP/4.4.1
X-Powered-By: PHP/4.4.1
Connection: close
Content-Type: text/html

<!-- masked --><html>
<head>
<title>Sparks Photography</title>

</head>
<frameset rows="100%,*" border="0">
<frame src="http://www.oostdyk.com/catherine/" frameborder="0">
<frame frameborder="0" noresize>
</frameset>
</html>

<!-- m -->
Connection closed by foreign host.

And then it proceeds to tell me that it thinks I'm using 1.1 even though I explicitly said 1.0.

Basically, GoDaddy's web server is fundamentally broken and not spec compliant. No browser should legitimately be showing data. Whoever wrote this web server should be repeatedly slapped with a wet noodle.

It's timing or flushing...

[gjh]

Case 1:
[canterbury:~] gjh% telnet forgreatergood.org 80
Trying 64.202.167.129...
Connected to forgreatergood.org.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /?ABCDEFGH
Connection closed by foreign host.

Case 2:
[canterbury:~] gjh% telnet forgreatergood.org 80
Trying 64.202.167.129...
Connected to forgreatergood.org.
Escape character is '^]'.
GET / HTTP/1.0
Host: forgreatergood.org

HTTP/1.1 302 Found
Date: Fri, 09 Dec 2005 01:15:53 GMT
Server: Apache/1.3.31 (Unix) mod_pointer/0.8 PHP/4.4.1
X-Redirected-By: mod_pointer - http://stderr.net/mod_pointer/
Location: http://www.wavepulse.net/forgreatergood
Connection: close
Content-Type: text/html; charset=iso-8859-1

....(message text)

The only difference was that with Case 2, I pasted in the request lines atomically, whereas in Case 1, I typed it line by line.

This is probably down to a brain dead content-switching device looking packet by packet instead of reassembling the stream. It is broken.

Greg

Re:baseless zealotry

[ehrichweiss]

This is old and inaccurate information based on text from his blog that was taken entirely out of context. Move along, nothing to see here.

Response from GoDaddy

[whitehatlurker]

I am somewhat surprised this hasn't been posted yet. The Apple discussion board has a few messages like this:

Thank you for contacting customer support. We appreciate you taking the time to write us.

The immediate response to this issue is to clear the Safari browser cache and reconnect. This solves 99% of the problems you described. From reseach on the Apple Support discussion boards, an issue with has been identified as a buggy Java update from Apple (J2SE 5.0) for Mac OS X 10.4.3. The only known workaround is to revert back to J2SE 1.4.2. Once that is done, Safari and Opera correctly resolve and forward domains.

Sincerely,

Bobby P.
GoDaddy.com
Customer Service Representative

Heh, maybe it's Sun's fault ;-) Anyway those with problems should drop back a Java version.

Re:Can anyone confirm this?

[alienw]

Browsers should not be doing anything like this to protect against redirect loops, except having a redirection limit. What GoDaddy is doing is perfectly RFC compliant, except for the relative URL (which a lot of places violate, actually). This does seem to be a bug in Safari and Opera. Opera in particular does some pretty aggressive caching, which is probably the problem here.

Re:Blaming Apple? Who? Got a Source?

[simdan]

Try going to the linked Apple Support discussion board page and looking at this message timestamped Dec 7, 2005 3:32 PM:

I just wrote and received the following response from Godaddy:

"Response from WILLIAM G
12/07/2005 04:23 PM
Dear Matthew Wanderer

Thank you for contacting Customer Support.

Apple recently released an update to Java, Version J2SE 5.0. There is a bug in this release that has caused forwarding to stop working properly for both the browsers Safari and Opera on Mac OS X. You will need to report this bug to Apple Computers using the Report Bugs feature from within the Safari menu. This situation was caused by changes in Java and not GoDaddy. Because of that a resolution is completely out of our hands. I apologize for any inconvenience that this may cause.

Please let us know if we can help you in any other way."

They claim it's the Java update, which is what I thought it might be in my initial post. Frustrating is just the beginning here because I quite sure Apple will pass the buck as well, and why wouldn't they.

GoDaddy's on crack

[multipartmixed]

And the JRE version is just a red-herring.

30s of investigation on my park shows that their HTTP header parsing is fux0red. The biggest problem IMNSHO is that they are *not* looking for the end of the HTTP header, they are looking for the end of the FIRST PACKET.

This will break any HTTP client which uses multiple write()s to the socket while constructing its query, and either takes too long for Nagle, has the Nagle Algorithm turned off, or constructs a query which exceeds the MTU of any network between itself and GoDaddy.

GoDaddy is badly broken. The programmer who wrote the redirect code DID NOT read Stevens UNP or TCP/IP Illustrated Volume I.

The JRE "fix" is probably just a default state change of Nagle or the HTTP header contruction code in some fancy-pants object. (I'm a UNIX C hacker, not a Java guy).

Re:Can anyone confirm this?

[nova_planitia]

The problem is GoDaddy doesn't know what the #&#&^ they are doing. BTW, this not only affects Safari and Opera, it affects every since CLI browser I know... I tried resolving this with GoDaddy when this started around Nov 28 (the weekend of Thanksgiving). I talked to tech support and sent the captured network traffic showing them the URL from the 302 header was pointing to the wrong "/?ABCDEFGH" relative URL. I clearly said that they should forward this to the people in charge of the servers. 1) Response number one: Check your firewall settings. We don't see this so it must be your fault. 2) I email them, explaining this is happening from computers I have access to in Virginia and Minnesota and four different ISPs. This is not a configuration error on my computer. I again send them the network packets I captured. The response, please check your firewall settings and it can't be their problem because no one else is seeing the problem. 3) I end up investigating starting with a Google search for "/?ABCDEFGH" and find out that Apple's Webkit developers have been seeing the problem. They seem to consider it to be a glitch in Safari that it doesn't handle the malformed 302 header from GoDaddy (the same way that certain old tags keep getting supported even if they are depreciated). Firefox and MSIE work because they handle a malformed 302 header with a relative URL link (which is, I believe, not supposed to be used). My impression was the people on them mailing were trying to patch WebKit. I forwarded the following email to GoDaddy tech support,

From my investigation of the problem locally, it seems to be that the problem is with browsers that don't handle the "302 Moved Temporarily" header returned by your domain forwarding web server properly. It appears that most command line clients also don't handle "302 Moved Temporarily" properly.This seems to be what is expected to happen:

1. User requests / from your server because they were directed there by a DNS identification of http://family.cabanela.com/ pointing to your server.
2. GoDaddy Server redirects to /?ABCDEFGH ("302 Moved Temporarily")
3. User requests /?ABCDEFGH
4. GoDaddy Server prepares new version of /, and redirects user back to /
5. User requests / again from GoDaddy servers.
6. this time, the page loads with the Location redirect properly set tohttp://iparrizar.stcloudstate.edu/~juan/family/

The reason this doesn't work in my command line browsers is that they give up at step 2. When they get the "302 Moved Temporarily" HTTP response, they don't load the URL to which the server reports the page has moved.The reason this works in Firefox is that Firefox continues to step 3, loading the URL to which the server reports the page has moved.The reason this works in my command line browsers after you try it in Firefox is that Firefox has already gone through steps 1-4, so your server apparently already has the "real" / ready to go. So this appears to be an issue due to the fact that you must cache the URLs to be forwarded on your server and once in the cache, they play friendly with any browser (on any client, I suspect). [snip]

The reply from GoDaddy's tech support:

Thank you for contacting customer support. We are aware of the issue being experienced with forwarding. There is a problem with the connection between several ISP's and our servers. Unfortunately, as the problem is not with our servers, we are not able to fix it ourselves, nor do we have an ETA for when the problem will be resolved. Your sites are currently forwarding correctly. You should be able to verify this with and . Your ISP may be able to give you more information.

It's of course never their fault. I am dropping GoDaddy. If their tech support is this awful when handed the bloody details, I hate to think how they deal with people without a clue.

Re:Can anyone confirm this?

[jon787]

The spec also specifies that the end of the request is marked by \r\n\r\n. GoDaddy is responding to the request after the initial "GET / HTTP/1.1\r\n" instead of waiting for two consecutive CRLF delimiters.

Re:Blaming Apple? Who? Got a Source?

[nova_planitia]

This is bullshit. Try using the command line lynx or curl browsers... it fails with them and they are not dependent on Java. This is a configuration error on GoDaddy's servers that started around November 28. Before then Lynx, Curl, Safari, and Opera all worked find when interacting with their forwarding service.

Re:Can anyone confirm this?

[TheArtfulTodger]

I know this was only an example, but I'm pretty sure closing TD tags are not necessary.

From: http://www.w3.org/TR/REC-html32#table :
The start tags for TH and TD are always needed but the end tags can be left out.

Re:But it doesn't loop

[Black Perl]

Right. It doesn't loop in firefox, which was used for that trace. Opera and Safari behave differently, evidently caching the 302 response for "/".

I'm not sure why GoDaddy is doing the double-moved-temporarily thing. How are other ISPs performing the redirects?