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."

Can anyone confirm this?

[RandyOo (61821)]

I just put my wife's photography site online yesterday, and it's hosted via domain masking/redirection from godaddy. Anyone with Oprah or Safari have trouble getting to it?

http://www.photosparks.com/ [photosparks.com]

Re:Can anyone confirm this?

[Carthag (643047)]

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?

[larry bagina (561269)]

ok...

$ nc www.photosparks.com 80
GET / HTTP/1.1
HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /?ABCDEFGH

$ nc www.photosparks.com 80
GET /?ABCDEFGH HTTP/1.1
HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /

Note - the response came back instantly -- before I could enter the Host: header.

Re:Can anyone confirm this?

[larry bagina (561269)]

ok, I had ethereal [slashdot.org] 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?

[Malc (1751)]

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 [slashdot.org]

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 [slashdot.org]

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 [slashdot.org]

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

[...]

Re:Can anyone confirm this?

[Chmarr (18662)]

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

Re:Can anyone confirm this?

[morcheeba (260908)]

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

Re:Can anyone confirm this?

[Qbertino (265505)]

Yepp. Me too. Blank on Safari.

Broken redirect usage. This provider is the suxx0rsz.
You are in the postition to ask them to change the
behaviour of their servers to RFC compliance.
I'd suggest you do it.
And change the provider if they don't fix it.

Re:Can anyone confirm this?

[Gojira Shipi-Taro (465802)]

Well it takes a surfboard the size of CVN-65 Enterprise, but she can just manage it with a stiff breeze. *

oh... the web. No. She can't do that.

* Yes I know she's in her "waning" phase and not particularly fat right now, but just wait.

Re:Can anyone confirm this?

[dgatwood (11270)]

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.

Re:Can anyone confirm this?

[jimbolaya (526861)]

While I applaud the posters' detective work, this is a test that a network admin at GoDaddy should and could do if he had half a braincell.

Re:Can anyone confirm this?

[nova_planitia (444881)]

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/ [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/ [stcloudstate.edu]

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?

[ciscoguy01 (635963)]

This is NOT UNUSUAL. Typical of someone who tests his web work with IE. IE fixes ridiculous stuff on the fly, like the site I looked at some time ago in Firefox with several hundred TD tags and only two /TD tags. It didn't work with Firefox but IE rendered it OK.

For the sake of interoperability it's usually good to design things so they "always work". But if you are testing it makes sense to test with a less robust platform than IE. You WANT to find the problems, not mask them.

This does not change the fact that yeah, GoDaddy's server IS likely broken. But if they hadn't tested with IE they would have known.

Apple's fault?

[crayz (1056)]

GoDaddy blames Apple for both Safari and Opera simultaneously ceasing to work? That's a nice trick

Re:Apple's fault?

[Mr. Underbridge (666784)]

GoDaddy blames Apple for both Safari and Opera simultaneously ceasing to work? That's a nice trick

They're blaming global warming too.

Re:Apple's fault?

[tsm_sf (545316)]

"being a medical doctor, and speaking a little conversational french, I feel it's safe to say that I know more than a little about browser compliance"

-Michael Crichton

Blaming Apple? Who? Got a Source?

[Alaren (682568)]

Anyone want to tell me what the source is on this "GoDaddy is blaming Apple?" According to what I hear, the problem actually has to do with some Cisco equipment.

This is a problem that needs to be addressed, sure, but it seems silly to say "GoDaddy is blaming Apple" without some kind of, I don't know, press release or official company statement. And no, I'm afraid the "educated guesses" of GoDaddy support personnel do not constitute GoDaddy as an entity blaming Apple.

Re:Blaming Apple? Who? Got a Source?

[simdan (207210)]

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.

Re:Blaming Apple? Who? Got a Source?

[nova_planitia (444881)]

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:Apple's fault?

[Kelson (129150)]

Not only two browsers, but two browsers using entirely different code bases and developed by entirely different groups of people.

Had it been, say, Camino and Firefox, or Safari and Konqueror, I might be a little more inclined to believe them, but come on!

Of course, they claim it's the OS-wide Java update... but how exactly is that supposed to be related to native code that uses HTTP?

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."

Godaddy sucks

[humankind (704050)]

The best solution to this problem is to avoid Godaddy entirely. They are fast making Verisign and ICANN look reputable.

Re:Godaddy sucks

[ihbphx (931623)]

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.

Re:Godaddy sucks

[merc (115854)]

Disclaimer: I do not work for Godaddy, in fact I work for a competing ISP and domain registrar that is also in GoDaddy's local area:

That being said, I must say that everything I have ever learned by talking to existing Godaddy customers, Godaddy employees whom I know, and observation in general, I can say that what I have noticed conflicts with what you have said entirely. I realize that there is always bound to be someone who is going to be unhappy (e.g., you can't satisfy all the people all of the time) but honestly your complaint is the first I've ever heard of with Godaddy -- which is pretty amazing considering how many customers they have.

Another thing I like about them in particular, in addition to (again, what I believe, personally) their good reputation as a web hosting services and domain registrar is that they do not tolerate spammers and make a fairly decent effort to terminate them as they discover them (e.g., source: news.admin.net-abuse.email

My $0.02.

Weird.

[DeadSea (69598)]

I fired up firefox with LiveHTTPHeaders extension and here is what I found when I contacted www.catalogueofships.com:

> GET / HTTP/1.1

< HTTP/1.x 302 Moved Temporarily
< Location: /?ABCDEFGH

> GET /?ABCDEFGH HTTP/1.1

< HTTP/1.x 302 Moved Temporarily
< Location: /

> GET / HTTP/1.1

< HTTP/1.x 200 OK

It appears that the page is redirecting and then redirecting back. I can imagine that would confuse some browsers. Especially if the browser cached the first redirect and didn't actually fetch the same exact page a second time.

There is probably something in the http spec about not caching temporary redirects. In fact not caching them makes perfect sense to me. So safari has a bug of some sort with redirect caching.

However, what the server is doing seems to be fairly brain dead as well. Why would you redirect away and then redirect back? It appears that there is not cookie set between the two. The server must be remembering your IP address and serving you actual content on the second hit from that IP Address. That would certainly explain the "teaching issue" that causes safari to work with these sites after visiting with firefox.

The only explanation that I can come up with is that somebody discovered this obscure caching bug in safari and built a system to expose it. It seems that the blank page problem would be easy to fix in either safari or the web server.

Re:Weird.

[g0at (135364)]

Yeah, and those Location: headers are broken as well. Although most browsers accept them and act as implied, they really should specify fully-formed URLs -- i.e. beginning with http://server/ [server] as opposed to a relative path fragment.

-b

Relative 302s violate the RFC

[Evro (18923)]

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 [w3.org]

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 o

Re:Weird.

[Strepsil (75641)]

It's not necessarily caching at fault - I used curl to take a look at this from a shell under OS X. It's weird. First, I got the redirect you saw. I requested the "?ABCDEFGH" page. This didn't give me a 302 redirect.

---
$ curl -D - http://www.photosparks.com/?ABCDEFGH

HTTP/1.0 200 OK
Connection: Close
Pragma: no-cache
cache-control: no-cache
Content-Type: text/html; charset=iso-8859-1

<HTML><HEAD><META HTTP-EQUIV="Refresh" CONTENT="0.1; URL=/?ABCDEFGH">
<META HTTP-EQUIV="Pragma" CONTENT="no cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
</HEAD></HTML>
---

Ever since then, I get the intended result for every redirect page under GoDaddy, in _Safari_ as well as from curl.

The first time I tested this, I got the white page. All I've done since is make a couple of requests from the command line, and now it all works.

It's not related to caching or cookies, that's for sure. It must be IP tracking somewhere along the line.

redirects from GoDaddy appear hosed

[jeavis (198354)]

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.

GoDaddy can...

[pebs (654334)]

GoDaddy can GoFuckThemSelves

GoDaddy's Fault

[jay2003 (668095)]

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, not allowing client headers

[EMR (13768)]

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.

Re:GoDaddy's Fault

[jay2003 (668095)]

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.

This is NOT a bug

[od05 (915556)]

This is not a bug but a feature in Safari. Internet Explorer and Firefox will display http://www.stealyourpassword.com/paypal [stealyourpassword.com] as http://www.paypal.com/ [paypal.com] while Safari will show it's true address. It's to avoid forwarding addresses that are spoofed.

Re:This is NOT a bug

[NeutronCowboy (896098)]

Can't replicate the stealyourpassword.com issue with Firefox 1.5. when I click on your link, all I get is a server not found error, and the URL bar clearly displays the full URL. Care to explain the bug a little further?

Re:This is NOT a bug

[nystul555 (579614)]

I think the parent poster was using stealyourpassword.com as a fake example. stealyourpassword.com is not a registered domain name.

Re:This is NOT a bug

[SendBot (29932)]

stealyourpassword.com is not a registered domain name.

It is now:

Domain Name: STEALYOURPASSWORD.COM
Status: ACTIVE
Creation Date: 08-dec-2005

Blaming apple??

[geniusj (140174)]

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:Blaming apple??

[sharkey (16670)]

another vendor (whom I can't name)

Does it rhyme with "Crisco"?

From the website....

[UncleRage (515550)]

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. :|

It's timing or flushing...

[gjh (231652)]

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/ [stderr.net]
Location: http://www.wavepulse.net/forgreatergood [wavepulse.net]
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

The real cause

[Brandybuck (704397)]

The current belief is malformed headers, an invalid 302 header with a bogus location and a redirect loop.

That's not it. That's not it by a mile. The real cause of this problem is that GoDaddy never bothered testing their site with anything other than two browsers. Hell, they probably only tested it with IE and the FF users just got lucky.

What the fsck is it with web developers that they never ever test their pages? And what is it with their managers that they don't insist on testing?

Re:Should be easy to troubleshoot

[Anonymous Coward]

Anyone sufficiently technically savvy, with a knowledge of the HTTP protocol, with 5 min of free time could tcpdump the traffic to immediately identify the origin of the problem.

We are talking about Apple users here.

Re:Should be easy to troubleshoot

[Bogtha (906264)]

Less of the elitism please. While it's very simple to confirm that they are sending malformed headers, that's not to say that the headers are the origin of the problem. In case you haven't noticed, the web is full of broken code, just because you see something that doesn't adhere to the RFC, it doesn't mean that this is necessarily what is causing the problem.

Re:baseless zealotry

[the phantom (107624)]

I would agree with you except for the fact that the error is obviously on GoDaddy's end, and they are blaming Apple. If the article stated that there was a problem, and GoDaddy had no intention of fixing it because it only affect a small number of people, it would be unfortunate, but expected. As it is, they are trying to pass the buck and blame someone else. Also, point of fact, Safari and Opera have more than 0.25% marketshare. So, all things considered, your post is a troll. Rather than mod you down, I thought I should explain why you will be modded down by someone else shortly.

Re:baseless zealotry

[Phroggy (441)]

Statistics [hitslink.com]

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:The real cause (in Safari)

[EMR (13768)]

actually I highly doubt it's the improper location header. AS a LARGE number of website (espcially PHP ones) do the same violation. I believe the real violation is the godaddy server NOT accepting any client headers after the initial "GET / HTTP/1.1" request line.. The client is supposed to send TWO carriage return/line feed combinations before the server response allow the the client to send User-Agent and Host: headers. Godaddy's servers are not allowing this. So opera and safari are trying to send th

Re:GAP.com

[heinousjay (683506)]

You've got bigger problems than that, my friend - someone who claims to love you keeps trying to dress you in gap clothes

GoDaddy's on crack

[multipart/mixed (163409)]

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:It's a pity.

[SleepyHappyDoc (813919)]

Define an agile browser, please.

An agile browser is one that can perform complex gymnastic manoevres while simultanously rendering web pages.