当我们在查看网页源文件的时候，在源文件顶部往往都能看到：
| <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” ”http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”> |
或者
| <html xmlns=”http://www.w3.org/1999/xhtml” …> |
如上面刷蓝的代码，都含有指向W3C网站服务器的关于HTML DTDs 和 命名空间相关的网页资源。W3C管理员的纠结正源于此。
我们注意到上面的刷蓝标签，其实并不是HTML中的超链接，他们是仅仅用来作为确认的URIs，这是以机器能读懂的方式告诉计算机“这个文档是HTML”。并且，通常计算机软件程序并不需要去抓取这些URI资源，并且一定不需要反反复复地去抓取这些资源！然而，W3C服务器却接收到“令人震惊”的“出奇地大”的对这些资源的请求：每天收到超过130，000，000次的请求，占用宽带使用350Mbps，仅仅是抓取几年未变样的资源文件。
这时，W3C管理员声音很哽咽，感觉得出这事对他影响很大，鬼斧很认真地接着听她讲下去，了解到：
这么大的网站访问请求，有绝大多数来自处理各种标记（HTML， XML， XSLT， SVG）的系统，如在验证DTD或schema的处理期间发起的请求。
要处理这么大的请求给W3C带来了昂贵的成本和代价：服务器！带宽！还要花费大量人力来分析这些请求数据、限制或阻止一些大量重复的请求。“很郁闷，我们宁愿用这些钱去做其他事情！比如改进、完善W3C和WEB社区的软件和服务。而不是这样被耗这么多钱！”W3C管理员显然有点小怒了。
“前不久，我们加了一个系统来监控这些请求，并对一些泛滥的请求直接发送503错误，并根据具体的垃圾请求形式作为对应的响应信息返回。我们希望是这些个对W3C发起大量请求的软件的开发者或部署管理员能够注意到这个错误，并且对他们的软件做一些必要的修正。”W3C管理员继续哽咽地讲到。听到这里我拍拍她的肩膀说“i am sorry！”表示同情。
“但是这些系统大多数依旧每日无数次地请求相同的DTDs，即使我们夜以继日给它们返回503错误也毫无效果，为啥这些系统这么讨厌！他们根本就不关系这些请求！（对于一些请求源头，我们最后在TCP层对其IP进行了阻止。）”
“我们也鉴定出了一些导致对W3C大量请求的软件，并且联系了他们的负责人，告诉他们在对W3C进行DDos攻击。一些进行积极相应并及时修正了这些问题。不幸的是，有很多却拖延很长时间不给解决！还有大量的请求无法断定来源！”W3C管理员眼睛里夹杂着丝丝无奈。
“我多么希望这个问题可以一劳永逸地解决，做梦都想！这也是为了部署在W3C网站的所有软件着想。所以我给那些软件作者一些建议，希望他们不要再无休止地折磨W3C”：
1、关注您的HTTP响应码。
编程的一个好习惯是检查您的响应码，否则当一些错误发生的时候您压根就不知道。
2、善用 HTTP caching/expiry 信息。
W3C网站的资源是以友好缓存方式存储的。我们的DTDs 和 schemata都明确定义过期时间为90天以上，所以压根没必要一天不停息地请求。（有一个公司的许多IP地址从W3C请求DTD，一个IP地址每天请求竟然超过10万次。）
3、如果您的软件实现采用HTTP，可允许超速缓存。
4、负责关注您对外出的网络流量。
5、在实际需要的时候才抓取外部内容。
最后，W3C管理员抛出一个问题：“W3C可以忽略这个问题，响应所有的用户请求吗？”
假如有一天，我们目前处理10亿多DTD请求，变为100亿次的DTD请求该会怎么办？
总的来说，对于W3C过度的DTD网络流量（W3C‘s Excessive DTD Traffic ）这个事，“W3C管理员很生气，郁闷、惆怅、纠结”，这比墨西哥湾漏油更让她寝食难安。
网林鬼斧最后给W3C管理员了三点建议，希望对其有所帮助：
1、首先得让大家知道这个事情、逐渐重视这个事，这一点阅网博客带头给大家进行国内首次的书面介绍。
2、在中国做一些更明了的使用手册或帮助手册，如果中文帮助做好，错误的时间、错误的请求是可以最大程度避免的。在做一份关于DTD使用经验更加简单明了方面，阅网博客愿意帮助W3C共同推进此事。（当然国外也是。）
3、希望W3C管理员注意身体，该吃吃该喝喝，有事别往心里隔，积极处理此事，但是别因此日渐憔悴，多出去转转、多陪陪家人：） 哈哈，有点扯远了。
最后，希望W3C管理员头疼的这个问题早日得到解决。