Back to index
|void||init (in nsIURI aURI)|
|Initializes the URI checker. |
|void||asyncCheck (in nsIRequestObserver aObserver, in nsISupports aContext)|
|Begin asynchronous checking URI for validity. |
|Indicates whether the request is pending. |
|void||cancel (in nsresult aStatus)|
|Cancels the current request. |
|Suspends the current request. |
|Resumes the current request. |
|readonly attribute nsIChannel||baseChannel|
|Returns the base channel that will be used to verify the URI. |
|readonly attribute AUTF8String||name|
|The name of the request. |
|readonly attribute nsresult||status|
|The error status associated with the request. |
|The load group of this request. |
|The load flags of this request. |
|const unsigned long||LOAD_NORMAL = 0|
|No special load flags: |
|const unsigned long||LOAD_BACKGROUND = 1 << 0|
|Don't deliver status notifications to the nsIProgressEventSink, or keep this load from completing the nsILoadGroup it may belong to. |
|const unsigned long||INHIBIT_CACHING = 1 << 7|
|This flag prevents caching of any kind. |
|const unsigned long||INHIBIT_PERSISTENT_CACHING = 1 << 8|
|This flag prevents caching on disk (or other persistent media), which may be needed to preserve privacy. |
|const unsigned long||LOAD_BYPASS_CACHE = 1 << 9|
|Force an end-to-end download of content data from the origin server. |
|const unsigned long||LOAD_FROM_CACHE = 1 << 10|
|Load from the cache, bypassing protocol specific validation logic. |
|const unsigned long||VALIDATE_ALWAYS = 1 << 11|
|The following flags control the frequency of cached content validation when neither LOAD_BYPASS_CACHE or LOAD_FROM_CACHE are set. |
|const unsigned long||VALIDATE_NEVER = 1 << 12|
|const unsigned long||VALIDATE_ONCE_PER_SESSION = 1 << 13|
The URI checker is a component that can be used to verify the existance of a resource at the location specified by a given URI. It will use protocol specific methods to verify the URI (e.g., use of HEAD request for HTTP URIs).
Begin asynchronous checking URI for validity.
Notification will be asynchronous through the nsIRequestObserver callback interface. When OnStartRequest is fired, the baseChannel attribute will have been updated to reflect the final channel used (corresponding to any redirects that may have been followed).
Our interpretations of the nsIRequestObserver status codes: NS_BINDING_SUCCEEDED: link is valid NS_BINDING_FAILED: link is invalid (gave an error) NS_BINDING_ABORTED: timed out, or cancelled
|aObserver||The object to notify when the link is verified. We will call aObserver.OnStartRequest followed immediately by aObserver.OnStopRequest. It is recommended that the caller use OnStopRequest to act on the link's status. The underlying request will not be cancelled until after OnStopRequest has been called.|
|aContext||A closure that will be passed back to the nsIRequestObserver methods.|
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.
|aStatus||the reason for canceling this request.|
NOTE: most nsIRequest implementations expect aStatus to be a failure code; however, some implementations may allow aStatus to be a success code such as NS_OK. In general, aStatus should be a failure code.
Initializes the URI checker.
After this method is called, it is valid to further configure the URI checker by calling its nsIRequest methods. This method creates the channel that will be used to verify the URI. In the case of the HTTP protocol, only a HEAD request will be issued.
|aURI||The URI to be checked.|
Indicates whether the request is pending.
nsIRequest::isPending is true when there is an outstanding asynchronous event that will make the request no longer be pending. Requests do not necessarily start out pending; in some cases, requests have to be explicitly initiated (e.g. nsIChannel implementations are only pending once asyncOpen returns successfully).
Requests can become pending multiple times during their lifetime.
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.
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.
The following flags control the frequency of cached content validation when neither LOAD_BYPASS_CACHE or LOAD_FROM_CACHE are set.
By default, cached content is automatically validated if necessary before reuse.
VALIDATE_ALWAYS forces validation of any cached content independent of its expiration time.
VALIDATE_NEVER disables validation of expired content.
VALIDATE_ONCE_PER_SESSION disables validation of expired content, provided it has already been validated (at least once) since the start of this session.
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.