Open Bug 277878 Opened 20 years ago Updated 2 years ago

nsWebBrowserPersist doesn't handle a content-length of -1

Categories

(Firefox :: File Handling, defect)

x86
Linux
defect

Tracking

()

People

(Reporter: bzbarsky, Unassigned)

Details

(Keywords: dataloss)

See nsWebBrowserPersist::OnDataAvailable -- it has the following wonderful code: 874 PRInt32 channelContentLength = -1; 875 if (!cancel && 876 NS_SUCCEEDED(channel->GetContentLength(&channelContentLength))) 877 { 878 // if we get -1 at this point, we didn't get content-length header 879 // assume that we got all of the data and push what we have; 880 // that's the best we can do now 881 if ((-1 == channelContentLength) || 882 ((channelContentLength - (aOffset + aLength)) == 0)) 883 { 884 NS_ASSERTION(channelContentLength != -1, "no content length"); 885 // we're done with this pass; see if we need to do upload 886 nsCAutoString contentType; 887 channel->GetContentType(contentType); 888 // if we don't have the right type of output stream then it's a local file 889 nsCOMPtr<nsIStorageStream> storStream(do_QueryInterface(data->mStream)); 890 if (storStream) 891 { 892 data->mStream->Close(); 893 data->mStream = nsnull; // null out stream so we don't close it later 894 rv = StartUpload(storStream, data->mFile, contentType); 895 if (NS_FAILED(rv)) 896 { 897 cancel = PR_TRUE; 898 } 899 } 900 } 901 } So the upshot is that if the channel doesn't know its content-length we will kill off the output stream on each ODA. Which means we'll reopen the file on each ODA, with MakeOutputStreamFromFile, which passes default flags, which mean PR_TRUNCATE. So the upshot is that for any channel that has a content-length of -1 (some HTTP responses, say, or IMAP channels), it looks like we'll only write the data in the last ODA to the file... Even if that is not the case (though I fail to see how), asserting on a normal condition like "unknown content length" is just wrong.
Assignee: file-handling → nobody
QA Contact: ian → file-handling
Product: Core → Firefox
Version: Trunk → unspecified
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.