Confirm
431
edits
Changes
→Implemention Questions
* If no Content-Type header was present in the HTTP reply, we sniff the content and possibly set up StreamConverters, etc. (the text/plain sniffer was mentioned in particular). We may need to teach StreamConverters to switch threads.
** Or--since missing Content-Type is quite rare for HTML content, which is all we're currently proposing to parse off-main-thread, we could simply refuse to redirect in this case?
* TransactionPumps and the HttpProtocolHandler will probably need work to work with thread redirection.
* We may want to move some logic that currently runs in the main thread into the necko thread: gzip converstion came up in particular.
* cache: no one seems to know exactly what mods might need to be made to the cache to support multiple simultaneous readers.
* A large number of classes would need modification: nsURI, nsChannels, IIOService and the various nsIProtocolHandlers.
* Authorization boxes would need to be popped up from non-main threads
* Many of the necko APIs have been implemented by Javascript extensions, which would suddenly need to be thread-safe.
