You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.
nsIUploadChannel
This interface is implemented by channels that wish to support the notion of uploading a data stream. The upload stream must be set prior to the invocation of
asyncOpen
on the channel. The interface is scriptable.Sets a stream to be uploaded by this channel.
Most implementations of this interface require that the stream:
(1) implement threadsafeaddRef
andrelease
(2) implementnsIInputStream::readSegments
(3) implementnsISeekableStream::seek
.Note: The history here is that some streams (from plugins) already have header (e.g., Content-Type and Content-Length) information prepended to the stream and other streams (from clients such as Mozilla Composer or other uploading applications that want to upload data streams without any knowledge of protocol specifications) don't. The decision was that both types of streams should be supported. For this reason, there is a special meaning for the
aContentType
parameter (see below).Syntax:
void nsIUploadChannel::setUploadStream( in nsIInputStream aStream, in ACString aContentType, in long aContentLength)
Parameters:
aContentType
: IfaContentType
is empty, the protocol will assume that no content headers are to be added to the uploaded stream and that any required headers are already encoded in the stream. In the case of http:, if this parameter is non-empty, then its value will replace any existing Content-Type header on the HTTP request. In the case of ftp: and file:, this parameter is ignored.
aContentLength
: A value of -1 indicates that the length of the stream should be determined by calling the stream'savailable
method.
nsresult:
Written by:Ellen Evans | Comments, questions, complaints?
Bug 143387 |