当前位置：文江博客知识库 en-US 文档 Mozilla Tech XPCOM Reference Interface nsIChannel

nsIChannel 编辑

netwerk/base/nsIChannel.idlScriptable This interface allows clients to construct 'GET' requests for specific protocols, and manage them in a uniform way. Inherits from: nsIRequest Last changed in Gecko 19.0 (Firefox 19.0 / Thunderbird 19.0 / SeaMonkey 2.16)

Once a channel is created (via nsIIOService.newChannel()), parameters for that request may be set by using the channel attributes, or by calling QueryInterface() to retrieve a subclass of nsIChannel for protocol-specific parameters. Then, the URI can be fetched by calling open() or asyncOpen(). After a request has been completed, the channel is still valid for accessing protocol-specific results. For example, QueryInterfacing to nsIHttpChannel allows response headers to be retrieved for the corresponding http transaction.

This interface must be used only from the XPCOM main thread.

Implemented by netwerk/base/src/nsBaseChannel.cpp and netwerk/protocol/http/src/nsHttpChannel.cpp.

Method overview

void asyncOpen(in nsIStreamListener aListener, in nsISupports aContext);

nsIInputStream open();

Attributes

Attribute	Type	Description
`contentCharset`	`ACString`	The character set of the channel's content if available and if applicable. This attribute only applies to textual data. Setting contentCharset before the channel has been opened provides a hint to the channel on what the charset should be. The behavior is similar to contentType. The value of the contentCharset attribute is a mixed case string.
`contentLength`	`int64_t`	The length of the data associated with the channel if available. A value of -1 indicates that the content length is unknown. Note: As of Gecko 19.0, this parameter changed from `long` to `int64_t`. In earlier versions callers could get the "content-length" property as 64-bit value by QueryInterfacing the channel to `nsIPropertyBag2`, if that interface is exposed by the channel.
`contentType`	`ACString`	The MIME type of the channel's content if available. Note: The content type can often be wrongly specified (For example wrong file extension, wrong MIME type, wrong document type stored on a server and so on.), and the caller most likely wants to verify with the actual data. Setting contentType before the channel has been opened provides a hint to the channel as to what the MIME type is. The channel may ignore this hint in deciding on the actual MIME type that it will report. Setting contentType after onStartRequest has been fired or after `open()` is called will override the type determined by the channel. Setting contentType between the time that `asyncOpen()` is called and the time when onStartRequest is fired has undefined behavior at this time. The value of the contentType attribute is a lowercase string. A value assigned to this attribute will be parsed and normalized as follows: Any parameters (delimited with a ';') will be stripped. If a charset parameter is given, then its value will replace the the contentCharset attribute of the channel. The stripped contentType will be lowercased. Any implementation of `nsIChannel` must follow these rules.
`notificationCallbacks`	`nsIInterfaceRequestor`	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. The channel may also query the notification callbacks from its load group if its notification callbacks do not supply the requested interface. Interfaces commonly requested include: `nsIProgressEventSink`, `nsIPrompt`, and `nsIAuthPrompt` / `nsIAuthPrompt2`. When the channel is done, it must not continue holding references to this object. Note: A channel implementation should take care when "caching" an interface pointer queried from its notification callbacks. If the notification callbacks are changed, then a cached interface pointer may become invalid and may therefore need to be re-queried.
`originalURI`	`nsIURI`	The original URI used to construct the channel. This is used in the case of a redirect or URI "resolution" (For example resolving a resource: URI to a file: URI) so that the original pre-redirect URI can still be obtained. This is also used as the RI of the document resulting from the channel, unless the channel has the LOAD_REPLACE flag set. This is never `null`. Attempts to set it to `null` must throw. Note: This is distinctly different from the http Referer (referring URI), which is typically the page that contained the original URI (accessible from `nsIHttpChannel`.)
`owner`	`nsISupports`	The owner, corresponding to the entity that is responsible for this channel. 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.
`securityInfo`	`nsISupports`	Transport-level security information (if any, else null) corresponding to the channel, normally presented through the interfaces `nsITransportSecurityInfo` and `nsISSLStatusProvider` Read only.
`URI`	`nsIURI`	The URI corresponding to the channel. Its value is immutable. Read only.

Constants

Channel specific load flags:

Bits 23-31 are reserved for future use by this interface or one of its derivatives (For an example see nsICachingChannel).

Constant	Value	Description
`LOAD_DOCUMENT_URI`	`16`	Set (for example by the docshell) to indicate whether or not the channel corresponds to a document URI.
`LOAD_RETARGETED_DOCUMENT_URI`	`17`	If the end consumer for this load has been retargeted after discovering its content, this flag will be set:
`LOAD_REPLACE`	`18`	This flag is set to indicate that this channel is replacing another channel. This means that: The stream listener this channel will be notifying was initially passed to the `asyncOpen()` method of some other channel This channel's URI is a better identifier of the resource being accessed than this channel's `originalURI`. This flag can be set, for example, for redirects or for cases when a single channel has multiple parts to it (and thus can follow `onStopRequest` with another `onStartRequest`/`onStopRequest` pair, each pair for a different request).
`LOAD_INITIAL_DOCUMENT_URI`	`19`	Set (for example by the docshell) to indicate whether or not the channel corresponds to an initial document URI load (for example link click).
`LOAD_TARGETED`	`20`	Set (For example by the `URILoader`) to indicate whether or not the end consumer for this load has been determined.
`LOAD_CALL_CONTENT_SNIFFERS`	`21`	If this flag is set, the channel should call the content sniffers as described in `netwerk/build/nsNetCID.h` about `NS_CONTENT_SNIFFER_CATEGORY`. See nsIContentSniffer [en-US] Note: Channels may ignore this flag; however, new channel implementations should only do so with good reason.
`LOAD_CLASSIFY_URI`	`22`	This flag tells the channel to use URI classifier service to check the URI when opening the channel.

Methods

asyncOpen()

Asynchronously open this channel. Data is fed to the specified stream listener as it becomes available. The stream listener's methods are called on the thread that calls asyncOpen and are not called until after asyncOpen returns. If asyncOpen returns successfully, the channel promises to call at least onStartRequest and onStopRequest.

If the nsIRequest object passed to the stream listener's methods is not this channel, an appropriate onChannelRedirect notification needs to be sent to the notification callbacks before onStartRequest is called. Once onStartRequest is called, all following method calls on aListener will get the request that was passed to onStartRequest.

If the channel's and loadgroup's notification callbacks do not provide an nsIChannelEventSink when onChannelRedirect would be called, that's equivalent to having called onChannelRedirect.

If asyncOpen returns successfully, the channel is responsible for keeping itself alive until it has called onStopRequest on aListener or called onChannelRedirect.

Implementations are allowed to synchronously add themselves to the associated load group (if any).

void asyncOpen(
  in nsIStreamListener aListener,
  in nsISupports aContext
);

Parameters

aListener: The nsIStreamListener implementation.
aContext: An opaque parameter forwarded to aListener's methods.

Exceptions thrown

NS_ERROR_ALREADY_OPENED: If the channel is reopened
NS_ERROR_PORT_ACCESS_NOT_ALLOWED: If the specified port is in the nsIOService forbidden port list.

open()

Synchronously open the channel.

Note: Extensions should not call this method, because it tends to fail when a request is redirected, rather than redirecting transparentlyNote: nsIChannel 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. Like any other nsIChannel method it must not be called on any thread other than the XPCOM main thread.

nsIInputStream open();

Parameters

None.

Return value

Blocking input stream to the channel's data.

Exceptions thrown

NS_ERROR_IN_PROGRESS: If the channel is reopened.

nsIChannel 编辑

Method overview

Attributes

Constants

Methods

asyncOpen()

Parameters

Exceptions thrown

open()

Parameters

Return value

Exceptions thrown

See also

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

词条统计

友情链接

nsIChannel 编辑

Method overview

Attributes

Constants

Methods

asyncOpen()

Parameters

Exceptions thrown

open()

Parameters

Return value

Exceptions thrown

See also

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

词条统计

友情链接

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。