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.
This interface allows for control of a particular request, providing status information, including caching status, and the ability to stop, suspend, or resume loading. It is scriptable.
Checks whether a particular request is pending or has reached completion. Suspended requests are still considered pending.
Cancels the current request. This will close any open input or output streams and terminate any async requests. Users should normally pass
NS_BINDING_ABORTED, although other errors may also be passed. The error passed in will become the value of the status attribute.
aStatusto be a failure code; however, some implementations may allow
aStatusto be a success code such as
NS_OK. In general,
aStatusshould be a failure code.
Syntax:void nsIRequest::cancel(in nsresult aStatus)
Suspends the current request. This may have the effect of closing any underlying transport (in order to free up resources), although any open streams remain logically opened and will continue delivering data when the transport is resumed.
Note: some implementations are unable to immediately suspend, and may continue to deliver events already posted to an event queue. In general, callers should be capable of handling events even after suspending a request.
Resumes the current request. This may have the effect of re-opening any underlying transport and will resume the delivery of data to any open streams.
Gets the name of the request. Often this is the URI of the request.
Gets the error status associated with the request.
Gets and sets the load group of this request. While pending, the request is a member of the load group. It is the responsibility of the request to implement this policy.
Gets and sets the load flags of this request. Bits 0-15 are reserved. When added to a load group, this request's load flags are merged with the load flags of the load group.
See below for load flag values. They may be or'd together.
Indicates no special load flags.
Don't deliver status notifications to the
nsIProgressEventSink, or keep this load from completing the
nsILoadGroupit may belong to.
Prevents caching of any kind. This flag does not, however, prevent cached content from being used to satisfy this request.
Prevents caching on disk (or other persistent media), which may be needed to preserve privacy. For HTTPS, this flag is set automatically.
Forces an end-to-end download of content data from the origin server. This flag is used for a shift-reload. It has higher precedence than
Loads from the cache, bypassing protocol specific validation logic. This flag is used when browsing via history. It is not recommended for normal browsing as it may likely violate reasonable assumptions made by the server and confuse users.
Forces validation of any cached content independent of its expiration time
This set of three flags controls the frequency of cached content validation when neither
LOAD_FROM_CACHEare set. By default, cached content is automatically validated if necessary before reuse.
Note to Implementors: These flags are intended for normal browsing, and they should therefore not apply to content that must be validated before each use. Consider, for example, a HTTP response with a "Cache-control: no-cache" header. According to RFC2616, this response must be validated before it can be taken from a cache. Breaking this requirement could result in incorrect and potentially undesirable side-effects.
Disables validation of expired content.
Disables validation of expired content, provided it has already been validated (at least once) since the start of this session.
| Written by:Ellen Evans | Comments, questions, complaints?