Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

GoDaddy Serves Blank Pages to Safari & Opera 397

Posted by CowboyNeal from the not-so-much-with-the-go dept.
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."
This discussion has been archived. No new comments can be posted.

GoDaddy Serves Blank Pages to Safari & Opera More

GoDaddy Serves Blank Pages to Safari & Opera

Comments Filter:

  • Can anyone confirm this? (Score:5, Interesting)

    by RandyOo ( 61821 ) on Thursday December 08, 2005 @07:13PM (#14215184) Homepage
    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]
    • 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
    • Anyone with Oprah...have trouble...?

      I didn't know Oprah could surf the web!

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

      • 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? (Score:5, Informative)

          by Malc ( 1751 ) on Thursday December 08, 2005 @07:50PM (#14215468)
          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

          [...]
          • 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.
            • I looked back over the HTTP RFC, but it doesn't describe in detail what a browser should or should not do to avoid redirect loops. It's perfectly reasonable to stop once you've been redirected back to the original page and simply display the content given by the server -- which, according to the RFC, "SHOULD" contain a note about the redirect for the user's sake.

              An RFC is not usually a detailed specification, so requiring certain specific behavior from a browser is unwise if that behavior is not clearly st

      • Re:Can anyone confirm this? (Score:5, Informative)

        by Chmarr ( 18662 ) on Thursday December 08, 2005 @07:35PM (#14215361)
        Yeah, that's go-daddy's fault all right. The Location field is supposed to contain the FULL URL, not just a relative one.
        • 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.
    • 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).
    • this page comes up blank for me too. oddly i haven't seen one site, other than this one, with that issue. i guess i don't visit sites by people hosted on godaddy.
    • Doesn't work for me on Safari 2.0.2 (416.13) on 10.4.3.
    • Works fine here.
      Opera Version 8.51
      Build 1462
      Platform Linux
      System i686, 2.6.14-halb5
      Qt library 3.3.5
      Java Java Runtime Environment installed
    • 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
    • When I click on the Gallery link I get a 1" x 1" box with a lower case "f" in it.
      Most likely, If i click the "f" a macromedia flash animation will appear. I'm not willing to take that chance. :)

      I'm using firefox on linux and I use the firefox flash blocker extension.
      • My mistake was showing the wife that jAlbum supports skins. She HAD to use the one with flash, no matter how hard I tried to convince her otherwise. It's really not that bad, though. Promise.
    • Yup. Blank page, blank source. Safari 2.0.2 (416.13).

      -b
    • 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.
    • I'm using Safari 2.0.2 (416.13) on OS X 10.4.3
    • It seems that the bulk of the discussion at the Apple forums has been that question, repeated and rephrased.

      Q: I don't understand the problem. Here is my site, can you see it?

      A: No.

      Q: I don't understand the problem. Here is my site, can you see it?

      A: No.

      Q: I don't understand the problem. Here is my site, can you see it?

      A: No.

      Guys, we get it. No one can see your site! It's either malformed headers coming out of a "domain masking" service that you knew was designed to deceive browsers into display

  • Apple's fault? (Score:5, Insightful)

    by crayz ( 1056 ) on Thursday December 08, 2005 @07:13PM (#14215186) Homepage
    GoDaddy blames Apple for both Safari and Opera simultaneously ceasing to work? That's a nice trick
    • GoDaddy blames Apple for both Safari and Opera simultaneously ceasing to work? That's a nice trick

      They're blaming global warming too.

    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Thursday December 08, 2005 @08:01PM (#14215530)
      Comment removed based on user account deletion

      • Re:Blaming Apple? Who? Got a Source? (Score:5, Informative)

        by simdan ( 207210 ) on Thursday December 08, 2005 @09:28PM (#14216021) Homepage
        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 sucks (Score:2, Informative)

    by dmf415 ( 218827 ) *
    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!

  • FTFA (Score:5, Informative)

    by Anonymous Coward on Thursday December 08, 2005 @07:14PM (#14215189)
    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."
    • This is accurate. Apple is not being blamed. It looks like whoever wrote the article never spoke to GoDaddy's PR department.

    • Re:FTFA (Score:3, Insightful)

      by schon ( 31600 )
      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.

      Huh? If you're using a product to supply a service, and that product is wonky and affects your service, then by definition it's a glitch in your service.

      To be simpler: It's either the service you're providing, or the client. You've established that it's not the client.
  • Hasn't this happened to IE yet?

    • Re:And why (Score:2, Offtopic)

      by Locke2005 ( 849178 )
      Obviously, because web designers test their pages with IE and only with IE. I personally was unable to get pages with javascript generated slider controls to layout the same way in IE and netscape/mozilla, and didn't test with Safari simply because my employer didn't see fit to provide me with a Mac (one of my coworkers tested it with Safari and reported back the results). Let's not kid ourselves, NONE of the browsers are 100% standards compliant, and getting pages to work the same way in all browsers out t

  • Godaddy sucks (Score:5, Insightful)

    by humankind ( 704050 ) on Thursday December 08, 2005 @07:19PM (#14215229) Journal
    The best solution to this problem is to avoid Godaddy entirely. They are fast making Verisign and ICANN look reputable.

    • Re:Godaddy sucks (Score:5, Informative)

      by ihbphx ( 931623 ) on Thursday December 08, 2005 @07:40PM (#14215396)
      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.

      • One word: Chargeback.

        If you have a problem with a company that charges your credit card incorrectly or fraudulently you talk to the company first, but you talk to your credit card issuer second and initiate a chargeback.
    • Other than this incident, what has GoDaddy done wrong?

    • Re:Godaddy sucks (Score:5, Insightful)

      by merc ( 115854 ) <slashdot@upt.org> on Thursday December 08, 2005 @08:43PM (#14215780) Homepage
      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. (Score:5, Interesting)

    by DeadSea ( 69598 ) * on Thursday December 08, 2005 @07:20PM (#14215239) Homepage Journal
    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. (Score:3, Insightful)

      by 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
    • 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. (Score:5, Interesting)

      by Strepsil ( 75641 ) <mike@bremensaki.com> on Thursday December 08, 2005 @07:41PM (#14215406) Homepage
      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.
    • It seems that the HTTP/1.1 specification says the user agent should detect redirection loops, though it doesn't say what to do about them nor how they should be detected. It does say however that 302 responses are not cachable without Expires or Cache-Control headers.

      10.3 Redirection 3xx

      This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and

    • Its some sort of load balancing using layer 7. First request goes to the default box/cluster to determine where to put you and probably sets a cookie to load balance off of(so the load balance router can use it to route off of). Then your redirected but this time your have a cookie so the load balance router can route you to the right box/cluster which was determine by the prior request. The last redirect is just to strip off the querystring.

      More info on cookie switching [foundrynet.com]

  • These guys are really shiny and nice looking, electronically, but their tech support is terrible. they never add requested features, cannot acknowledge outages and their billing department is clueless.

    I've gone back to running my own server just out of sheer frustration!

    They own many of their value added companies, but act as if they don't so they can pass the buck/point fingers.

    They spend more on marketing than on servicing.
    • It seems to me that GoDaddy takes advantage of people who have little technical knowledge, and tries to push them to buy services they don't need.

      Sometimes GoDaddy [godaddy.com] web pages are so full of ads for dubious services that it is difficult to find the useful content.

  • redirects from GoDaddy appear hosed (Score:5, Informative)

    by jeavis ( 198354 ) on Thursday December 08, 2005 @07:23PM (#14215271)
    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... (Score:3, Funny)

    by pebs ( 654334 ) on Thursday December 08, 2005 @07:28PM (#14215304) Homepage
    GoDaddy can GoFuckThemSelves

  • GoDaddy's Fault (Score:5, Informative)

    by jay2003 ( 668095 ) on Thursday December 08, 2005 @07:35PM (#14215363)

    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.

    • 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.
    • Firefox is tolerant of the spec violation and Safari and Opera are apparently not.
      This isn't true. Opera certainly copes with relative URI in the location header. Whaterver the problem is, it isn't that simple.

      • Re:GoDaddy's Fault (Score:5, Informative)

        by jay2003 ( 668095 ) on Thursday December 08, 2005 @08:18PM (#14215646)
        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 (Score:5, Interesting)

    by od05 ( 915556 ) on Thursday December 08, 2005 @07:44PM (#14215434)
    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.
  • Did this guy just call my browser Oprah?

  • Blaming apple?? (Score:5, Informative)

    by geniusj ( 140174 ) on Thursday December 08, 2005 @07:49PM (#14215465) Homepage
    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.

  • The real cause (in Safari) (Score:2, Interesting)

    by Anonymous Coward
    The problem with the 302 response is not the relative URL in the Location: header, it's the lack of blank line after the headers. The RFC requires this and Safari's network stack doesn't (yet) support tolerance of this quirk.
    • 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

  • From the website.... (Score:5, Informative)

    by UncleRage ( 515550 ) on Thursday December 08, 2005 @07:50PM (#14215474)
    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. :|
  • GoDaddy's superbowl commercial for this year should be BLANK! That'd be an accurate representation of the service.
  • Recently, I needed to register a couple of domain names. While Go Daddy was the cheapest by $2 or $3/yr, their abominable web site was enough to drive me to name.com. Anyone who designs a cluttered, in-your-face web site like GoDaddy's probably has no clue about web development. I figured that it was only a matter of time before compatibility failed with such a poor design.

  • It's timing or flushing... (Score:5, Informative)

    by gjh ( 231652 ) on Thursday December 08, 2005 @08:26PM (#14215701)

    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

  • crawlers - bad for SEO (Score:3, Interesting)

    by dindi ( 78034 ) on Thursday December 08, 2005 @10:12PM (#14216229)
    I actually heard a year ago that many people dropped Godaddy, because they were serving different/incorrect/empty pages
    to crawlers and people's sites were dropping from SE indexes like crazy ...

    dunno, never used them, but since those conplaints by many I did not want to go with them...

    Now it makes me wonder what googlebot, msnbot, yahoo and other members of the artificial gang see from these 302/404/no source sites .... good chance that they do not see crap, and your godaddy site goes down the loo...

  • The real cause (Score:4, Insightful)

    by Brandybuck ( 704397 ) on Thursday December 08, 2005 @10:12PM (#14216235) Homepage Journal
    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?

Slashdot Top Deals

In specifications, Murphy's Law supersedes Ohm's.

Close