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.