View Single Post
Posts: 56 | Thanked: 8 times | Joined on Nov 2007
#318
If I saw over 7GB in an afternoon, I can only imagine how badly pounded tablets-dev.nokia.com was?

In theory, tablets-dev.nokia.com should paddle through this easily, as requests (at least http requests) to that host are *supposed* to be resolved by Akamai's global content delivery service, not directly from Nokia.

Code:
# from the west coast of NA
% ping tablets-dev.nokia.com
PING a1341.g.akamai.net (80.67.74.128): 56 data bytes
64 bytes from 80.67.74.128: icmp_seq=0 ttl=58 time=33.386 ms

% curl -I tablets-dev.nokia.com
HTTP/1.1 504 Gateway Time-out
Server: AkamaiGHost
Mime-Version: 1.0

# And now from the east coast of NA
% ping tablets-dev.nokia.com
PING a1341.g.akamai.net (77.67.111.200): 56 data bytes
64 bytes from 77.67.111.200: icmp_seq=0 ttl=59 time=69.867 ms

% curl -I tablets-dev.nokia.com
HTTP/1.1 504 Gateway Time-out
In this context, a Gateway timeout almost certainly points the finger back at NOKIA; either connectivity was insufficient to seed Akamai's network, let alone the user community, or NOKIA has muffed up cache-control and any other requirements made of it by Akamai.


From Requirements for Surrogates in the HTTP, proposed to the IETF and written by an Akamai employee, we can see what Akamai means by 504 Gateway time-out:

A 504 Gateway Timeout response SHOULD be sent under any of the
following conditions:
o DNS failure when resolving the origin server
o no route to origin server
o refused connection to origin server
o connection timeout to origin server


Unless proven otherwise, the finger has to point towards NOKIA; global delivery of content is Akamai's primary, bread-winning, business - its reasonable to assume they know what they are doing in this regard.

Last edited by wetcoast; 2007-12-19 at 15:58.
 

The Following 2 Users Say Thank You to wetcoast For This Useful Post: