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.
nsIChannel
This interface allows clients to construct "GET" requests for specific protocols, and manage them in a uniform way. Once a channel is created (via
nsIIOService::newChannel
), parameters for that request may be set by using the channel attributes, or by QI'ing to a subclass ofnsIChannel
for protocol-specific parameters. Then, the URI can be fetched by callingnsIChannel::open
ornsIChannel::asyncOpen
.After a request has been completed, the channel is still valid for accessing protocol-specific results. For example, QI'ing to
nsIHttpChannel
allows response headers to be retrieved for the corresponding http transaction.Synchronously open the channel.
Note: Implementations are not required to implement this method. Moreover, since this method may block the calling thread, it should not be called on a thread that processes UI events.
Syntax:
nsIInputStream nsIChannel::open()Parameters:
Returns:
Asynchronously open this channel. Data is fed to the specified stream listener as it becomes available.
Syntax:
void nsIChannel::asyncOpen( in nsIStreamListener aListener, in nsISupports aContext)Parameters:
nsresult:
Gets and sets the original URI used to construct the channel. This is used in the case of a redirect or URI "resolution" (e.g. resolving a resource: URI to a file: URI) so that the original pre-redirect URI can still be obtained.
Note: this is distinctly different from the http Referrer (referring URI), which is typically the page that contained the original URI (accessible from
nsIHttpChannel
).Gets the URI corresponding to the channel. Its value is immutable.
Gets and sets the owner, corresponding to the entity that is responsible for this channel. It is used by the security manager to grant or deny privileges to mobile code loaded from this channel.
Note: this is a strong reference to the owner, so if the owner is also holding a strong reference to the channel, care must be taken to explicitly drop its reference to the channel.
Gets and sets the notification callbacks for the channel. This is set by clients who wish to provide a means to receive progress, status and protocol-specific notifications. If this value is
null
, the channel implementation may use the notification callbacks from its load group. Interfaces commonly requested include:nsIProgressEventSink
,nsIPrompt
, andnsIAuthPrompt.
Gets transport-level security information (if any) corresponding to the channel.
Gets and sets the MIME type of the channel's content if available.
Note: the content type can often be wrongly specified (e.g., wrong file extension, wrong MIME type, wrong document type stored on a server, etc.), and the caller most likely wants to verify with the actual data.
Gets and sets the character set of the channel's content if available and if applicable. This attribute only applies to textual data.
Gets and sets the length of the data associated with the channel if available. A value of -1 indicates that the content length is unknown.
Channel specific load flag used (e.g., by the uriloader and docshell) to indicate whether or not the channel corresponds to the toplevel document.
Channel specific load flag, set if the end consumer for this load has been retargeted after discovering its content.
Channel specific load flag, set to indicate that onStopRequest may be followed by another onStartRequest/onStopRequest pair. It is used, for example, by the multipart/replace stream converter.
Written by:Ellen Evans | Comments, questions, complaints?
Bug 143387 |