Talk:Mozilla Firefox/Settings

From Gentoo Linux Wiki

Go out and experiment with that dialog people :) Sam 04:28, 12 Apr 2005 (GMT)

I don't use Firefox myself, but depending on the response from others I think this article is worth being linked to from Main Page. Yay, nay? -Tro 04:58, 12 Apr 2005 (GMT)

Certainly! Sam 07:37, 12 Apr 2005 (GMT)

Personally, I think that the http pipelining stuff needs to be either removed, or recommend a change to much, much lower than one hundred, as its very inconsiderate to webmasters to be attempting to open up up to 100 connections at a time.

Good article! I wrote a fairly long guide to Firefox a while ago (should update it soon). Check out: http://www.nawaz.org/wiki/index.php?title=Firefox

Feel free to steal from it whatever is appropriate. As you can see, it's already in Wiki! format. So you just have to copy and paste. One tip I think that should be here is:

Registering new protocols

Ever come across a link that goes like rtsp:// or irc:// and have your browser cough because of it? Hopefully, the software you use for IRC or viewing Real media will automatically register those protocols in Firefox. But if not...

Or I may add it in myself (but later...)

[edit] Changing global settings

These tips are all very fine - but how does one go about altering the settings globally so that all users' default settings are changed? -Freso 13:07, 14 March 2006 (GMT)

[edit] Pipelining

The wiki says: Warning: Using pipelineing is against the HTTP standards. The reason is that it has the same effect as a very low level DoS attack, use this very carefully or not at all.

However the W3C in the protocol definition (http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html) says: 8.1.2.2 Pipelining

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

Clients which assume persistent connections and pipeline immediately after connection establishment SHOULD be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.

Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request.

So I'm not sure the wiki is write in saying it is against the http standard. Would appreciate some input on this before making an edit.

I agree with you. Since pipelining is defined as part of HTTP/1.1 in RFC 2616 (which you quoted), it is most definately part of the standard. Furthermore, the quoted page also says:

• By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.

• HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time.

• Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to determine the congestion state of the network.

It can be concluded that pipelining is not at all similar to a DoS-attack, but it is a good thing for both server and clients. My guess would be that the initial author confused it with "prefetching linked pages in the background", which can also be done by some FF extension, IIRC. Prefetching is truly close to a DoS-attack and should generally be avoided.

[edit] restore old-style tab-close-buttons

browser.tabs.closeButtons     3