Package: kazehakase Version: 0.4.2-1 Kazehakase's automated favicon request handling ignores network.http.max-connections-per-server constraints and has none of its own in direct violation of rfc2616 section 8.1.4. [2]
Kazehakase's automated favicon request handling also overrides the standard practice of using a rel attribute defined in a profile. Kazehakase's automated favicon request handling, as an automated (or "robot") user-agent, should follow robots.txt rules. Kazehakase's automated favicon request handling, as a noninteractive tranfer, cannot be interrupted by any means other than closing Kazehakase, even including attempting to stop it by closing the frame that prompted the request. Kazehakase's automated favicon request handling generates a favicon request for every page visited, regardless of whether it's been cached, isn't there, or if the page is locally generated. This results in numerous requests on XSLT (and presumably AJAX/FRAMEs/IFRAMEs/what have you, but I didn't bother testing those ones) client-side renderings, immediately guaranteeing RFC violation. Kazehakase's automated favicon request handling goes against the express wishes of the W3 to avoid HTTP request, HTTP connection, and URI namespace pollution. [1] It seems to me that childish, broken, and irresponsible features designed to let a browser run amok over the wishes of users, administrators, RFCs, and the W3 are better suited to and more characteristic of AOL. Or Firefox. [1] http://www.w3.org/2005/10/howto-favicon [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html
signature.asc
Description: Digital signature
