1. Factoring nsIChannel into a protocol specific part, the nsIChannel, and a socket specific, the nsITransport.
2. Derive the nsIChannel from a nsIRequest.
2. Changes the notification system from necko and the URILoader to pass the nsIRequest interface instead of nsIChannel interface.
This goal stems from wanting to be able to have active AsyncRead and AsyncWrite operations on nsSocketTransport.
This is desired because it would greatly simplify the task of maintaining persistent/reusable socket connections
for FTP, HTTP, and Imap (and potentially other protocols). The problem with the existing nsIChannel interface is
that it does not allow one to selectively suspend just one of the read or write operations while keeping the other active.
The full details of the change on written up in the netlib newsgroup.
r=darin@netscape.comsr=rpotts@netscape.com
git-svn-id: svn://10.0.0.236/trunk@86717 18797224-902f-48f8-a5cc-f745e15eee43
have an external app that can handle the url. otherwise return NS_ERROR_UNKNOWN_PROTOCOL so we'll throw up an alert
dialog later on.
sr=sspizter
git-svn-id: svn://10.0.0.236/trunk@86497 18797224-902f-48f8-a5cc-f745e15eee43
as this code has been reconsolidated in the base class for
all to use. For everyone, if the mime type is unknown or octet,
then try to guess a content type by file extension in doContent.
Also, if we can't find a mime type, create a new one for all platforms
so we don't need to bring up the ucth dialog.
sr=sspitzer
git-svn-id: svn://10.0.0.236/trunk@86441 18797224-902f-48f8-a5cc-f745e15eee43
I've decided to move that functionality over to nsILocaFile where it makes more sense.
git-svn-id: svn://10.0.0.236/trunk@85680 18797224-902f-48f8-a5cc-f745e15eee43
we are already done with the download. Break apart
SaveTodisk and LaunchWithTempFile into to separate
methods. never try to really open or save to disk
until we are sure we've brought up the progress window.
Bug #61947 --> pass in the initial time when we started the download via getDownloadInfo so
the progress dialog can use this information.
sr=sspitzer
git-svn-id: svn://10.0.0.236/trunk@85481 18797224-902f-48f8-a5cc-f745e15eee43
Bug #61947 --> pass in the initial time
when we started the download via getDownloadInfo so
the progress dialog can use this information.
git-svn-id: svn://10.0.0.236/trunk@85480 18797224-902f-48f8-a5cc-f745e15eee43
entry for this mime type.
Bug #57364 --> look up content type to file extension mappings using the windows mime registry.
Bug #65872 --> if we get a content type of unknown or octet, try to ignore that content type
and extract the extension from the url and looking that up to see if we can get a better
content type.
sr=sspitzer
git-svn-id: svn://10.0.0.236/trunk@85143 18797224-902f-48f8-a5cc-f745e15eee43
make sure the mime action is initialized with the right action.
sr=mscott
git-svn-id: svn://10.0.0.236/trunk@82862 18797224-902f-48f8-a5cc-f745e15eee43
and force any Refresh urls back through the original window
context that initiated the helper app download. This solves
the problem where the user clicks on a link to download
content (either to disk or to a helper app) and that document
contains both a redirect for the actual content and a REFRESH
header which is used to point at a page the content provider
wants to see after the download is complete.
sr=rpotts, r=sspizter
git-svn-id: svn://10.0.0.236/trunk@82140 18797224-902f-48f8-a5cc-f745e15eee43
use the status of the last request processed in loading the document to determine
success or failure. That's incorrect. Instead, test to see if the load group is being
canceled. If it is, use that as the status for the entire document. Otherwise, ignore
the status for the last request and instead use the status for the main document
(the default load channel).
sr=rpotts, r=sspitzer
git-svn-id: svn://10.0.0.236/trunk@81801 18797224-902f-48f8-a5cc-f745e15eee43
then go ahead and make the progress dialog go away again. r=sspitzer, sr=alecf
git-svn-id: svn://10.0.0.236/trunk@81687 18797224-902f-48f8-a5cc-f745e15eee43
