|
1 /* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */ |
|
2 /* This Source Code Form is subject to the terms of the Mozilla Public |
|
3 * License, v. 2.0. If a copy of the MPL was not distributed with this |
|
4 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ |
|
5 |
|
6 #include "nsIRequest.idl" |
|
7 |
|
8 interface nsIURI; |
|
9 interface nsIInterfaceRequestor; |
|
10 interface nsIInputStream; |
|
11 interface nsIStreamListener; |
|
12 |
|
13 /** |
|
14 * The nsIChannel interface allows clients to construct "GET" requests for |
|
15 * specific protocols, and manage them in a uniform way. Once a channel is |
|
16 * created (via nsIIOService::newChannel), parameters for that request may |
|
17 * be set by using the channel attributes, or by QI'ing to a subclass of |
|
18 * nsIChannel for protocol-specific parameters. Then, the URI can be fetched |
|
19 * by calling nsIChannel::open or nsIChannel::asyncOpen. |
|
20 * |
|
21 * After a request has been completed, the channel is still valid for accessing |
|
22 * protocol-specific results. For example, QI'ing to nsIHttpChannel allows |
|
23 * response headers to be retrieved for the corresponding http transaction. |
|
24 * |
|
25 * This interface must be used only from the XPCOM main thread. |
|
26 */ |
|
27 [scriptable, uuid(2a8a7237-c1e2-4de7-b669-2002af29e42d)] |
|
28 interface nsIChannel : nsIRequest |
|
29 { |
|
30 /** |
|
31 * The original URI used to construct the channel. This is used in |
|
32 * the case of a redirect or URI "resolution" (e.g. resolving a |
|
33 * resource: URI to a file: URI) so that the original pre-redirect |
|
34 * URI can still be obtained. This is never null. Attempts to |
|
35 * set it to null must throw. |
|
36 * |
|
37 * NOTE: this is distinctly different from the http Referer (referring URI), |
|
38 * which is typically the page that contained the original URI (accessible |
|
39 * from nsIHttpChannel). |
|
40 */ |
|
41 attribute nsIURI originalURI; |
|
42 |
|
43 /** |
|
44 * The URI corresponding to the channel. Its value is immutable. |
|
45 */ |
|
46 readonly attribute nsIURI URI; |
|
47 |
|
48 /** |
|
49 * The owner, corresponding to the entity that is responsible for this |
|
50 * channel. Used by the security manager to grant or deny privileges to |
|
51 * mobile code loaded from this channel. |
|
52 * |
|
53 * NOTE: this is a strong reference to the owner, so if the owner is also |
|
54 * holding a strong reference to the channel, care must be taken to |
|
55 * explicitly drop its reference to the channel. |
|
56 */ |
|
57 attribute nsISupports owner; |
|
58 |
|
59 /** |
|
60 * The notification callbacks for the channel. This is set by clients, who |
|
61 * wish to provide a means to receive progress, status and protocol-specific |
|
62 * notifications. If this value is NULL, the channel implementation may use |
|
63 * the notification callbacks from its load group. The channel may also |
|
64 * query the notification callbacks from its load group if its notification |
|
65 * callbacks do not supply the requested interface. |
|
66 * |
|
67 * Interfaces commonly requested include: nsIProgressEventSink, nsIPrompt, |
|
68 * and nsIAuthPrompt/nsIAuthPrompt2. |
|
69 * |
|
70 * When the channel is done, it must not continue holding references to |
|
71 * this object. |
|
72 * |
|
73 * NOTE: A channel implementation should take care when "caching" an |
|
74 * interface pointer queried from its notification callbacks. If the |
|
75 * notification callbacks are changed, then a cached interface pointer may |
|
76 * become invalid and may therefore need to be re-queried. |
|
77 */ |
|
78 attribute nsIInterfaceRequestor notificationCallbacks; |
|
79 |
|
80 /** |
|
81 * Transport-level security information (if any) corresponding to the channel. |
|
82 */ |
|
83 readonly attribute nsISupports securityInfo; |
|
84 |
|
85 /** |
|
86 * The MIME type of the channel's content if available. |
|
87 * |
|
88 * NOTE: the content type can often be wrongly specified (e.g., wrong file |
|
89 * extension, wrong MIME type, wrong document type stored on a server, etc.), |
|
90 * and the caller most likely wants to verify with the actual data. |
|
91 * |
|
92 * Setting contentType before the channel has been opened provides a hint |
|
93 * to the channel as to what the MIME type is. The channel may ignore this |
|
94 * hint in deciding on the actual MIME type that it will report. |
|
95 * |
|
96 * Setting contentType after onStartRequest has been fired or after open() |
|
97 * is called will override the type determined by the channel. |
|
98 * |
|
99 * Setting contentType between the time that asyncOpen() is called and the |
|
100 * time when onStartRequest is fired has undefined behavior at this time. |
|
101 * |
|
102 * The value of the contentType attribute is a lowercase string. A value |
|
103 * assigned to this attribute will be parsed and normalized as follows: |
|
104 * 1- any parameters (delimited with a ';') will be stripped. |
|
105 * 2- if a charset parameter is given, then its value will replace the |
|
106 * the contentCharset attribute of the channel. |
|
107 * 3- the stripped contentType will be lowercased. |
|
108 * Any implementation of nsIChannel must follow these rules. |
|
109 */ |
|
110 attribute ACString contentType; |
|
111 |
|
112 /** |
|
113 * The character set of the channel's content if available and if applicable. |
|
114 * This attribute only applies to textual data. |
|
115 * |
|
116 * The value of the contentCharset attribute is a mixedcase string. |
|
117 */ |
|
118 attribute ACString contentCharset; |
|
119 |
|
120 /** |
|
121 * The length of the data associated with the channel if available. A value |
|
122 * of -1 indicates that the content length is unknown. Note that this is a |
|
123 * 64-bit value and obsoletes the "content-length" property used on some |
|
124 * channels. |
|
125 */ |
|
126 attribute int64_t contentLength; |
|
127 |
|
128 /** |
|
129 * Synchronously open the channel. |
|
130 * |
|
131 * @return blocking input stream to the channel's data. |
|
132 * |
|
133 * NOTE: nsIChannel implementations are not required to implement this |
|
134 * method. Moreover, since this method may block the calling thread, it |
|
135 * should not be called on a thread that processes UI events. Like any |
|
136 * other nsIChannel method it must not be called on any thread other |
|
137 * than the XPCOM main thread. |
|
138 * |
|
139 * NOTE: Implementations should throw NS_ERROR_IN_PROGRESS if the channel |
|
140 * is reopened. |
|
141 */ |
|
142 nsIInputStream open(); |
|
143 |
|
144 /** |
|
145 * Asynchronously open this channel. Data is fed to the specified stream |
|
146 * listener as it becomes available. The stream listener's methods are |
|
147 * called on the thread that calls asyncOpen and are not called until |
|
148 * after asyncOpen returns. If asyncOpen returns successfully, the |
|
149 * channel promises to call at least onStartRequest and onStopRequest. |
|
150 * |
|
151 * If the nsIRequest object passed to the stream listener's methods is not |
|
152 * this channel, an appropriate onChannelRedirect notification needs to be |
|
153 * sent to the notification callbacks before onStartRequest is called. |
|
154 * Once onStartRequest is called, all following method calls on aListener |
|
155 * will get the request that was passed to onStartRequest. |
|
156 * |
|
157 * If the channel's and loadgroup's notification callbacks do not provide |
|
158 * an nsIChannelEventSink when onChannelRedirect would be called, that's |
|
159 * equivalent to having called onChannelRedirect. |
|
160 * |
|
161 * If asyncOpen returns successfully, the channel is responsible for |
|
162 * keeping itself alive until it has called onStopRequest on aListener or |
|
163 * called onChannelRedirect. |
|
164 * |
|
165 * Implementations are allowed to synchronously add themselves to the |
|
166 * associated load group (if any). |
|
167 * |
|
168 * NOTE: Implementations should throw NS_ERROR_ALREADY_OPENED if the |
|
169 * channel is reopened. |
|
170 * |
|
171 * @param aListener the nsIStreamListener implementation |
|
172 * @param aContext an opaque parameter forwarded to aListener's methods |
|
173 * @see nsIChannelEventSink for onChannelRedirect |
|
174 */ |
|
175 void asyncOpen(in nsIStreamListener aListener, in nsISupports aContext); |
|
176 |
|
177 /************************************************************************** |
|
178 * Channel specific load flags: |
|
179 * |
|
180 * Bits 23-31 are reserved for future use by this interface or one of its |
|
181 * derivatives (e.g., see nsICachingChannel). |
|
182 */ |
|
183 |
|
184 /** |
|
185 * Set (e.g., by the docshell) to indicate whether or not the channel |
|
186 * corresponds to a document URI. |
|
187 */ |
|
188 const unsigned long LOAD_DOCUMENT_URI = 1 << 16; |
|
189 |
|
190 /** |
|
191 * If the end consumer for this load has been retargeted after discovering |
|
192 * its content, this flag will be set: |
|
193 */ |
|
194 const unsigned long LOAD_RETARGETED_DOCUMENT_URI = 1 << 17; |
|
195 |
|
196 /** |
|
197 * This flag is set to indicate that this channel is replacing another |
|
198 * channel. This means that: |
|
199 * |
|
200 * 1) the stream listener this channel will be notifying was initially |
|
201 * passed to the asyncOpen method of some other channel |
|
202 * |
|
203 * and |
|
204 * |
|
205 * 2) this channel's URI is a better identifier of the resource being |
|
206 * accessed than this channel's originalURI. |
|
207 * |
|
208 * This flag can be set, for example, for redirects or for cases when a |
|
209 * single channel has multiple parts to it (and thus can follow |
|
210 * onStopRequest with another onStartRequest/onStopRequest pair, each pair |
|
211 * for a different request). |
|
212 */ |
|
213 const unsigned long LOAD_REPLACE = 1 << 18; |
|
214 |
|
215 /** |
|
216 * Set (e.g., by the docshell) to indicate whether or not the channel |
|
217 * corresponds to an initial document URI load (e.g., link click). |
|
218 */ |
|
219 const unsigned long LOAD_INITIAL_DOCUMENT_URI = 1 << 19; |
|
220 |
|
221 /** |
|
222 * Set (e.g., by the URILoader) to indicate whether or not the end consumer |
|
223 * for this load has been determined. |
|
224 */ |
|
225 const unsigned long LOAD_TARGETED = 1 << 20; |
|
226 |
|
227 /** |
|
228 * If this flag is set, the channel should call the content sniffers as |
|
229 * described in nsNetCID.h about NS_CONTENT_SNIFFER_CATEGORY. |
|
230 * |
|
231 * Note: Channels may ignore this flag; however, new channel implementations |
|
232 * should only do so with good reason. |
|
233 */ |
|
234 const unsigned long LOAD_CALL_CONTENT_SNIFFERS = 1 << 21; |
|
235 |
|
236 /** |
|
237 * This flag tells the channel to use URI classifier service to check |
|
238 * the URI when opening the channel. |
|
239 */ |
|
240 const unsigned long LOAD_CLASSIFY_URI = 1 << 22; |
|
241 |
|
242 /** |
|
243 * If this flag is set and a server's response is Content-Type |
|
244 * application/octet-steam, the server's Content-Type will be ignored and |
|
245 * the channel content will be sniffed as though no Content-Type had been |
|
246 * passed. |
|
247 */ |
|
248 const unsigned long LOAD_TREAT_APPLICATION_OCTET_STREAM_AS_UNKNOWN = 1 << 23; |
|
249 |
|
250 /** |
|
251 * Set to let explicitely provided credentials be used over credentials |
|
252 * we have cached previously. In some situations like form login using HTTP |
|
253 * auth via XMLHttpRequest we need to let consumers override the cached |
|
254 * credentials explicitely. For form login 403 response instead of 401 is |
|
255 * usually used to prevent an auth dialog. But any code other then 401/7 |
|
256 * will leave original credentials in the cache and there is then no way |
|
257 * to override them for the same user name. |
|
258 */ |
|
259 const unsigned long LOAD_EXPLICIT_CREDENTIALS = 1 << 24; |
|
260 |
|
261 /** |
|
262 * Access to the type implied or stated by the Content-Disposition header |
|
263 * if available and if applicable. This allows determining inline versus |
|
264 * attachment. |
|
265 * |
|
266 * Setting contentDisposition provides a hint to the channel about the |
|
267 * disposition. If a normal Content-Disposition header is present its |
|
268 * value will always be used. If it is missing the hinted value will |
|
269 * be used if set. |
|
270 * |
|
271 * Implementations should throw NS_ERROR_NOT_AVAILABLE if the header either |
|
272 * doesn't exist for this type of channel or is empty, and return |
|
273 * DISPOSITION_ATTACHMENT if an invalid/noncompliant value is present. |
|
274 */ |
|
275 attribute unsigned long contentDisposition; |
|
276 const unsigned long DISPOSITION_INLINE = 0; |
|
277 const unsigned long DISPOSITION_ATTACHMENT = 1; |
|
278 |
|
279 /** |
|
280 * Access to the filename portion of the Content-Disposition header if |
|
281 * available and if applicable. This allows getting the preferred filename |
|
282 * without having to parse it out yourself. |
|
283 * |
|
284 * Setting contentDispositionFilename provides a hint to the channel about |
|
285 * the disposition. If a normal Content-Disposition header is present its |
|
286 * value will always be used. If it is missing the hinted value will be |
|
287 * used if set. |
|
288 * |
|
289 * Implementations should throw NS_ERROR_NOT_AVAILABLE if the header doesn't |
|
290 * exist for this type of channel, if the header is empty, if the header |
|
291 * doesn't contain a filename portion, or the value of the filename |
|
292 * attribute is empty/missing. |
|
293 */ |
|
294 attribute AString contentDispositionFilename; |
|
295 |
|
296 /** |
|
297 * Access to the raw Content-Disposition header if available and applicable. |
|
298 * |
|
299 * Implementations should throw NS_ERROR_NOT_AVAILABLE if the header either |
|
300 * doesn't exist for this type of channel or is empty. |
|
301 * |
|
302 * @deprecated Use contentDisposition/contentDispositionFilename instead. |
|
303 */ |
|
304 readonly attribute ACString contentDispositionHeader; |
|
305 }; |