1 | <!-- |
---|
2 | Wt Configuration File. |
---|
3 | |
---|
4 | The Wt configuration file manages, for every Wt application, settings |
---|
5 | for session management, debugging, directory for runtime information |
---|
6 | such as session sockets, and some security settings. |
---|
7 | |
---|
8 | Settings may be specified globally, or for a single application path. |
---|
9 | |
---|
10 | The path should be as configured in the Wt build process, where it |
---|
11 | defaults to /etc/wt/wt_config.xml. It can be overridden in the environment |
---|
12 | variable WT_CONFIG_XML, or with the -c startup option of wthttpd. |
---|
13 | |
---|
14 | The values listed here are the default values, which are used when the |
---|
15 | declaration is missing or no configuration file is used. |
---|
16 | --> |
---|
17 | |
---|
18 | <server> |
---|
19 | |
---|
20 | <!-- Default application settings |
---|
21 | |
---|
22 | The special location "*" always matches. See below for an example |
---|
23 | of settings specific to a single application. |
---|
24 | --> |
---|
25 | <application-settings location="*"> |
---|
26 | |
---|
27 | <!-- Session management. --> |
---|
28 | <session-management> |
---|
29 | <!-- Every session runs within a dedicated process. |
---|
30 | |
---|
31 | This mode guarantees kernel-level session privacy, but as every |
---|
32 | session requires a seperate process, it is also an easy target |
---|
33 | for DoS attacks if not shielded by access control. |
---|
34 | |
---|
35 | It is also a convenient mode during development, as it is easy |
---|
36 | to enable disable debugging using valgrind, and it always starts |
---|
37 | the latest deployed executable for a new session. |
---|
38 | |
---|
39 | Note: currently only supported using the FastCGI connector |
---|
40 | --> |
---|
41 | |
---|
42 | <!-- |
---|
43 | <dedicated-process> |
---|
44 | <max-num-sessions>100</max-num-sessions> |
---|
45 | </dedicated-process> |
---|
46 | --> |
---|
47 | |
---|
48 | <!-- Multiple sessions within one process. |
---|
49 | |
---|
50 | This mode spawns a number of processes, and sessions are |
---|
51 | allocated randomly to one of these processes (you should not |
---|
52 | use this for dynamic FCGI servers, but only in conjunction |
---|
53 | with a fixed number of static FCGI servers. |
---|
54 | |
---|
55 | This requires careful programming, as memory corruption in one |
---|
56 | session will kill all of the sessions in the same process. You |
---|
57 | should debug extensively using valgrind. Also, it is your |
---|
58 | responsibility to keep session state not interfering and |
---|
59 | seperated. |
---|
60 | |
---|
61 | On the other hand, sessions are inexpensive, and this mode |
---|
62 | suffers far less from DoS attacks than dedicated-process mode. |
---|
63 | Use it for non-critical and well-debugged web applications. |
---|
64 | |
---|
65 | Note: wthttpd always uses exactly one process |
---|
66 | --> |
---|
67 | <shared-process> |
---|
68 | <num-processes>1</num-processes> |
---|
69 | </shared-process> |
---|
70 | |
---|
71 | <!-- Session tracking strategy. |
---|
72 | |
---|
73 | Possible values: |
---|
74 | Auto: cookies is available, otherwise URL rewriting |
---|
75 | URL: only URL rewriting |
---|
76 | --> |
---|
77 | <tracking>URL</tracking> |
---|
78 | |
---|
79 | <!-- How reload should be handled. |
---|
80 | |
---|
81 | When reload should (or rather, may) spawn a new session, then |
---|
82 | even in the case cookies are not used for session management, |
---|
83 | the URL will not be cluttered with a sessionid. |
---|
84 | However, WApplication::refresh() will never be called. |
---|
85 | --> |
---|
86 | <reload-is-new-session>true</reload-is-new-session> |
---|
87 | |
---|
88 | <!-- Session timeout (seconds). |
---|
89 | |
---|
90 | When a session remains inactive for this amount of time, it is |
---|
91 | cleaned up. |
---|
92 | --> |
---|
93 | <timeout>600</timeout> |
---|
94 | |
---|
95 | <!-- Server push timeout (seconds). |
---|
96 | |
---|
97 | When using server-initiated updates, the client uses |
---|
98 | long-polling requests. Proxies (including reverse |
---|
99 | proxies) are notorious for silently closing idle |
---|
100 | requests; the client therefore cancels the request |
---|
101 | periodically and issues a new one. This timeout sets |
---|
102 | the frequency. |
---|
103 | --> |
---|
104 | <server-push-timeout>50</server-push-timeout> |
---|
105 | </session-management> |
---|
106 | |
---|
107 | <!-- Settings that apply only to the FastCGI connector. |
---|
108 | |
---|
109 | To configure the wthttpd connector, use command line options, or |
---|
110 | configure default options in /etc/wt/wthttpd |
---|
111 | --> |
---|
112 | <connector-fcgi> |
---|
113 | <!-- Valgrind path |
---|
114 | |
---|
115 | If debugging is enabled and this path is not empty, then valgrind |
---|
116 | will be started for every shared process, or for every session |
---|
117 | which has ?debug appended to the command line. |
---|
118 | |
---|
119 | The variable is slighly misnamed. Not only a path can be set, |
---|
120 | but also options, like for example: |
---|
121 | |
---|
122 | /usr/bin/valgrind - -leak-check=full |
---|
123 | --> |
---|
124 | <valgrind-path></valgrind-path> |
---|
125 | |
---|
126 | <!-- Run directory |
---|
127 | |
---|
128 | Path used by Wt to do session management. |
---|
129 | --> |
---|
130 | <run-directory>/var/run/wt</run-directory> |
---|
131 | |
---|
132 | <!-- Number of threads per process |
---|
133 | |
---|
134 | This configures the size of the thread pool. You may |
---|
135 | want to change this value if you would like to support |
---|
136 | reentrant event loops, where you block one event loop |
---|
137 | using WDialog::exec() or related static |
---|
138 | methods. Everytime you enter such an event loop, one |
---|
139 | thread is blocked, and therefore the total number of |
---|
140 | sessions that reliably can do this is limited to the |
---|
141 | number of thread you have (minus one to unblock). |
---|
142 | |
---|
143 | For the built-in http connector, there is a similar |
---|
144 | config option that is specified in the whttpd config |
---|
145 | file or on the command line (-t). |
---|
146 | |
---|
147 | The default value is 1. |
---|
148 | --> |
---|
149 | <num-threads>1</num-threads> |
---|
150 | |
---|
151 | </connector-fcgi> |
---|
152 | |
---|
153 | <!-- Settings that apply only to the MS IIS ISAPI connector. |
---|
154 | |
---|
155 | To configure the wthttpd connector, use command line options, or |
---|
156 | configure default options in /etc/wt/wthttpd |
---|
157 | --> |
---|
158 | <connector-isapi> |
---|
159 | <!-- Number of threads per process |
---|
160 | |
---|
161 | This configures the number of threads that will be used |
---|
162 | to handle Wt requests. The IIS internal threads are never |
---|
163 | used to do any processing; all requests are forwarded to |
---|
164 | be handled in this threadpool. Rather than to configure a |
---|
165 | so-called 'web-garden' in IIS, increase this number. The |
---|
166 | ISAPI connector will not work correctly when a web-garden |
---|
167 | is configured. |
---|
168 | |
---|
169 | You may want to change this value if you would like to |
---|
170 | support more reentrant event loops, where you block one |
---|
171 | event loop using WDialog::exec() or related static |
---|
172 | methods. Everytime you enter such an event loop, one |
---|
173 | thread is blocked, and therefore the total number of |
---|
174 | sessions that reliably can do this is limited to the |
---|
175 | number of thread you have (minus one to unblock). |
---|
176 | |
---|
177 | You may also want to increase this number if your Wt |
---|
178 | application is regularly waiting for IO (databases, network, |
---|
179 | files, ...). If this number is too low, all threads could |
---|
180 | be waiting for IO operations to complete while your CPU |
---|
181 | is idle. Increasing the number of threads may help. |
---|
182 | |
---|
183 | Computing intensive applications may also increase this number, |
---|
184 | even though it is better to offload computations to a helper |
---|
185 | thread and user server push or a WTimer to check for |
---|
186 | completion of the task in order to keep your GUI responsive |
---|
187 | during the computations. |
---|
188 | |
---|
189 | The default value is 10. |
---|
190 | --> |
---|
191 | <num-threads>10</num-threads> |
---|
192 | |
---|
193 | <!-- Maximum Request Size spooled in memory (Kb) |
---|
194 | |
---|
195 | Normally, Wt keeps incoming requests (POST data) in memory. |
---|
196 | However, malicious users could send a big POST and as such |
---|
197 | use up all memory of your HTTP server. With this parameter, |
---|
198 | you tune how big a request can be before Wt spools it in a |
---|
199 | file before processing it. Legitimate big POST messages may |
---|
200 | occur when users are expected to upload files. |
---|
201 | |
---|
202 | See also max-request-size. |
---|
203 | |
---|
204 | The default value is 128K, which is more than enough for |
---|
205 | any interactive Wt event. |
---|
206 | --> |
---|
207 | <max-memory-request-size>128</max-memory-request-size> |
---|
208 | </connector-isapi> |
---|
209 | |
---|
210 | <!-- Javascript debug options |
---|
211 | |
---|
212 | Values: |
---|
213 | - true: JavaScript errors are not caught but the browser |
---|
214 | built-in debug options are used |
---|
215 | - stack: JavaScript errors are caught but also a stack trace |
---|
216 | is printed, useful for diagnosing a problem in production |
---|
217 | - false: JavaScript errors are caught and a simple error message |
---|
218 | is printed to indicate that something is terribly wrong |
---|
219 | --> |
---|
220 | <debug>false</debug> |
---|
221 | |
---|
222 | <!-- Log file |
---|
223 | |
---|
224 | When the log file is empty, or omitted, logging is done to |
---|
225 | stderr. This may end up in the web server error log file |
---|
226 | (e.g. for apache + fastcgi module), or on stderr (e.g. for |
---|
227 | the built-in httpd). |
---|
228 | --> |
---|
229 | <log-file></log-file> |
---|
230 | |
---|
231 | <!-- Logger configuration |
---|
232 | |
---|
233 | This configures the logger. With the default configuration, |
---|
234 | everything except for debugging messages are logged. |
---|
235 | |
---|
236 | The configuration is a string that defines rules for |
---|
237 | enabling or disabling certain logging. It is a white-space |
---|
238 | delimited list of rules, and each rule is of the form: |
---|
239 | |
---|
240 | [-]level : enables (or disables) logging of messages of |
---|
241 | the given level; '*' is a wild-card that matches all |
---|
242 | levels |
---|
243 | |
---|
244 | [-]level:scope : enables (or disables) logging of |
---|
245 | messages of the given level and scope; '*' is a wild-card |
---|
246 | that matches all levels or scopes. The default |
---|
247 | configuration is "* -debug", i.e. by default everything |
---|
248 | is logged, except for "debug" messages. |
---|
249 | |
---|
250 | Some other examples: |
---|
251 | |
---|
252 | "* -debug debug:wthttp": logs everything, including |
---|
253 | debugging messages of scope "wthttp", but no other |
---|
254 | debugging messages. |
---|
255 | |
---|
256 | "* -info -debug": disables logging of info messages |
---|
257 | in addition to debugging messages. |
---|
258 | |
---|
259 | Note debugging messages are only emitted when debugging |
---|
260 | has been enabled while building Wt. |
---|
261 | --> |
---|
262 | <log-config>* -debug</log-config> |
---|
263 | |
---|
264 | <!-- Maximum HTTP request size (Kb) |
---|
265 | |
---|
266 | Maximum size of an incoming POST request. This value must be |
---|
267 | increased when the user is allowed to upload files. |
---|
268 | --> |
---|
269 | <max-request-size>128</max-request-size> |
---|
270 | |
---|
271 | <!-- Session id length (number of characters) --> |
---|
272 | <session-id-length>16</session-id-length> |
---|
273 | |
---|
274 | <!-- DoS prevention: limit plain HTML sessions |
---|
275 | |
---|
276 | This is a simple measure which avoids Denial-of-Service |
---|
277 | attacks on plain HTML sessions, which are easy to mount in |
---|
278 | particular in the case of progressive bootstrap mode. |
---|
279 | |
---|
280 | This setting may be used to keep the ratio of plain HTML |
---|
281 | versus Ajax sessions under a certain ratio. Typically, most |
---|
282 | of your sessions will be Ajax sessions, and only a tiny |
---|
283 | fraction (e.g. less than 5%) will be plain HTML |
---|
284 | sessions. This ratio is only enforced when more than 20 sessions |
---|
285 | have been created. |
---|
286 | --> |
---|
287 | <plain-ajax-sessions-ratio-limit>1</plain-ajax-sessions-ratio-limit> |
---|
288 | |
---|
289 | <!-- DoS prevention: adds a puzzle to validate Ajax sessions |
---|
290 | |
---|
291 | This is a simple measure which avoids Denial-of-Service |
---|
292 | attacks on Ajax sessions. |
---|
293 | |
---|
294 | When enabled, a puzzle needs to be solved in the first Ajax |
---|
295 | request which eliminates agents that do not build a proper |
---|
296 | DOM tree. |
---|
297 | --> |
---|
298 | <ajax-puzzle>false</ajax-puzzle> |
---|
299 | |
---|
300 | <!-- Send the XHTML mime type when appropriate |
---|
301 | |
---|
302 | Wt renders XHTML1 (XML variant of HTML) that is backward-compatible |
---|
303 | with HTML. Using XHTML, Wt is capable of supporting XHTML-only |
---|
304 | features such as embedded SVG or MathML. |
---|
305 | |
---|
306 | When enabled, JWt sets an XHTML mime-type |
---|
307 | (application/xhtml+xml) when the browser reports support |
---|
308 | for it. Most notably, Internet Explorer does not support |
---|
309 | it. Because XHTML and HTML are slightly different with |
---|
310 | respect to default CSS rules, you may want to disable |
---|
311 | sending the XHTML mime-type alltogether, at least if you |
---|
312 | are not using SVG (used by the WPaintedWidget). --> |
---|
313 | <send-xhtml-mime-type>false</send-xhtml-mime-type> |
---|
314 | |
---|
315 | <!-- Do strict serialization of events. |
---|
316 | |
---|
317 | By default events are queued at the client-side, and |
---|
318 | transmitted to the server so that at any time only one |
---|
319 | request/response is pending. This scheme has a quality that |
---|
320 | resembles TCP: on a low-latency link you allow the |
---|
321 | transmission of many smaller requests, while on a high |
---|
322 | latency link, events will be propagated less often, but in |
---|
323 | batches. |
---|
324 | |
---|
325 | In any case, this scheme does not drop events, no matter |
---|
326 | how quickly they are generated. |
---|
327 | |
---|
328 | In rare cases, the scheme may result in unwanted behaviour, |
---|
329 | because the client-side is allowed to be slighly out of |
---|
330 | sync at the time an event is recorded with the server-side |
---|
331 | (and more so on high-latency links). The drastic |
---|
332 | alternative is to discard events while a response is |
---|
333 | pending, and can be configured by setting this option to |
---|
334 | true. |
---|
335 | --> |
---|
336 | <strict-event-serialization>false</strict-event-serialization> |
---|
337 | |
---|
338 | <!-- Enables web socket. |
---|
339 | |
---|
340 | By default Ajax and long polling are used to communicate |
---|
341 | between server and browser. |
---|
342 | |
---|
343 | By enabling web socket support, if the browser supports |
---|
344 | WebSockets, then WebSocket is the protocol used for |
---|
345 | communication between client and server. WebSockets are |
---|
346 | currently only supported by the built-in httpd Connector, |
---|
347 | which acts as both an HTTP and WebSocket server. The WebSocket |
---|
348 | protocol is intentionally not compatible with HTTP, through |
---|
349 | a special hand-shake mechanism, and requires |
---|
350 | that all (reverse) proxy servers also have explicit support |
---|
351 | for this protocol. |
---|
352 | |
---|
353 | This feature is still experimental: the Web Sockets RFC is |
---|
354 | still a draft. Wt implements up to version 17 of the draft |
---|
355 | (latest as of November 2011). |
---|
356 | --> |
---|
357 | <web-sockets>false</web-sockets> |
---|
358 | |
---|
359 | <!-- Redirect message shown for browsers without JavaScript support |
---|
360 | |
---|
361 | By default, Wt will use an automatic redirect to start the |
---|
362 | application when the browser does not support |
---|
363 | JavaScript. However, browsers are not required to follow |
---|
364 | the redirection, and in some situations (when using XHTML), |
---|
365 | such automatic redirection is not supported. |
---|
366 | |
---|
367 | This configures the text that is shown in the anchor which |
---|
368 | the user may click to be redirected to a basic HTML version |
---|
369 | of your application. |
---|
370 | --> |
---|
371 | <redirect-message>Load basic HTML</redirect-message> |
---|
372 | |
---|
373 | <!-- Whether we are sitting behind a reverse proxy |
---|
374 | |
---|
375 | When deployed behind a reverse proxy (such as Apache or Squid), |
---|
376 | the server location is not read from the "Host" header, |
---|
377 | but from the X-Forwarded-For header, if present. |
---|
378 | --> |
---|
379 | <behind-reverse-proxy>false</behind-reverse-proxy> |
---|
380 | |
---|
381 | <!-- Whether inline CSS is allowed. |
---|
382 | |
---|
383 | Some Wt widgets will insert CSS rules in the the inline |
---|
384 | stylesheet when first used. This can be disabled using this |
---|
385 | configuration option. |
---|
386 | |
---|
387 | Note: some widgets, such as WTreeView and WTableView, |
---|
388 | dynamically manipulate rules in this stylesheet, and will |
---|
389 | no longer work properly when inline-css is disabled. |
---|
390 | --> |
---|
391 | <inline-css>true</inline-css> |
---|
392 | |
---|
393 | <!-- The timeout before showing the loading indicator. |
---|
394 | |
---|
395 | The value is specified in ms. |
---|
396 | --> |
---|
397 | <indicator-timeout>500</indicator-timeout> |
---|
398 | |
---|
399 | <!-- Ajax user agent list |
---|
400 | |
---|
401 | Wt considers three types of sessions: |
---|
402 | - Ajax sessions: use Ajax and JavaScript |
---|
403 | - plain HTML sessions: use plain old server GETs and POSTs |
---|
404 | - bots: have clean internal paths and no persistent sessions |
---|
405 | |
---|
406 | By default, Wt does a browser detection to distinguish between |
---|
407 | the first two: if a browser supports JavaScript (and has it |
---|
408 | enabled), and has an Ajax DOM API, then Ajax sessions are chosen, |
---|
409 | otherwise plain HTML sessions. |
---|
410 | |
---|
411 | Here, you may indicate which user agents should or should |
---|
412 | not receive an Ajax session regardless of what they report as |
---|
413 | capabilities. |
---|
414 | |
---|
415 | Possible values for 'mode' or "white-list" or "black-list". A |
---|
416 | white-list will only treat the listed agents as supporting Ajax, |
---|
417 | all other agents will be served plain HTML sessions. A black-list |
---|
418 | will always server plain HTML sessions to listed agents and |
---|
419 | otherwise rely on browser capability detection. |
---|
420 | |
---|
421 | Each <user-agent> is a regular expression. |
---|
422 | --> |
---|
423 | <user-agents type="ajax" mode="black-list"> |
---|
424 | <!-- <user-agent>.*Crappy browser.*</user-agent> --> |
---|
425 | </user-agents> |
---|
426 | |
---|
427 | <!-- Bot user agent list |
---|
428 | |
---|
429 | Here, you can specify user agents that should be should be |
---|
430 | treated as bots. |
---|
431 | |
---|
432 | Each <user-agent> is a regular expression. |
---|
433 | --> |
---|
434 | <user-agents type="bot"> |
---|
435 | <user-agent>.*Googlebot.*</user-agent> |
---|
436 | <user-agent>.*msnbot.*</user-agent> |
---|
437 | <user-agent>.*Slurp.*</user-agent> |
---|
438 | <user-agent>.*Crawler.*</user-agent> |
---|
439 | <user-agent>.*Bot.*</user-agent> |
---|
440 | <user-agent>.*ia_archiver.*</user-agent> |
---|
441 | <user-agent>.*Twiceler.*</user-agent> |
---|
442 | </user-agents> |
---|
443 | |
---|
444 | <!-- Whether the progressive bootstrap is used. |
---|
445 | |
---|
446 | The default bootstrap method first senses whether there is Ajax |
---|
447 | support, and only then creates the application. |
---|
448 | |
---|
449 | The progressive bootstrap method first renders a plain HTML |
---|
450 | version and later upgrades to an Ajax version. |
---|
451 | --> |
---|
452 | <progressive-bootstrap>false</progressive-bootstrap> |
---|
453 | |
---|
454 | <!-- Set session-ID cookie |
---|
455 | |
---|
456 | In its default (and recommended) configuration, Wt does not |
---|
457 | rely on cookies for session tracking. |
---|
458 | |
---|
459 | Wt has several mechanisms in place to prevent session ID stealing: |
---|
460 | - for an Ajax session, the session ID is not shown in the URL, |
---|
461 | avoiding session ID stealing through a referer attack. |
---|
462 | - in case the session ID is present in the URL (e.g. for a plain |
---|
463 | HTML session), Wt will redirect links to images or external |
---|
464 | anchors through an intermediate page that censors the session ID |
---|
465 | |
---|
466 | In case of the loss of a session ID, the impact is minimized: |
---|
467 | - a full page refresh is not supported if the client IP address |
---|
468 | changes or the user-agent changes |
---|
469 | - an Ajax update is protected by other state which is not exposed |
---|
470 | in the URL |
---|
471 | |
---|
472 | To still enable a full page refresh when the client IP address |
---|
473 | changes, an additional cookie may be set which is used only |
---|
474 | for this purpose, and can be enabled using this setting. |
---|
475 | --> |
---|
476 | <session-id-cookie>false</session-id-cookie> |
---|
477 | |
---|
478 | <!-- Runtime Properties |
---|
479 | |
---|
480 | These properties may be used to adapt applications to their |
---|
481 | deployment environment. Typical use is for paths to resources |
---|
482 | that may or may not be shared between several applications. |
---|
483 | --> |
---|
484 | <properties> |
---|
485 | <!-- baseURL property |
---|
486 | |
---|
487 | The absolute URL at which the application is deployed |
---|
488 | (known to the user). This is needed only in two scenarios. |
---|
489 | |
---|
490 | a) use of relative URLs in included XHTML |
---|
491 | |
---|
492 | When you use relative URLs for images, etc... in |
---|
493 | literal XHTML fragments (e.g. in WTemplate), which need |
---|
494 | to resolve against the deployment path of the |
---|
495 | application. This will not work as expected in the |
---|
496 | presence of an internal application path. This URL is |
---|
497 | set as base URL in the HTML, against which relative |
---|
498 | URLs are resolved so that these work correctly |
---|
499 | regardless of the internal path. It is also used |
---|
500 | explicitly in any URL generated by the library. |
---|
501 | |
---|
502 | b) widgetset mode deployments |
---|
503 | |
---|
504 | Another situation in which you need to define the baseURL is |
---|
505 | when deploying a widgetset mode application behind a reverse |
---|
506 | proxy. A widgetset mode application uses only absolute URLs |
---|
507 | because it may be hosted in a web page from an entirely |
---|
508 | different domain. |
---|
509 | |
---|
510 | By default, no baseURL is specified, in which case Wt will |
---|
511 | avoid using absolute URLs. Relative URLs passed in API calls |
---|
512 | will be "fixed" so that they resolve against the location of the |
---|
513 | application deploy path, even in the presence of an |
---|
514 | internal path. |
---|
515 | --> |
---|
516 | <!-- <property name="baseURL">"http://mysite.com/app</property> --> |
---|
517 | |
---|
518 | <!-- resourcesURL property |
---|
519 | |
---|
520 | The URL at which the resources/ folder is deployed that |
---|
521 | comes distributed with Wt and contains auxiliary files |
---|
522 | used to primarily for styles and themes. |
---|
523 | |
---|
524 | The default value is 'resources/' |
---|
525 | --> |
---|
526 | <property name="resourcesURL">resources/</property> |
---|
527 | |
---|
528 | <!-- extBaseURL property |
---|
529 | |
---|
530 | Used in conjunction with Ext:: widgets, and points to the |
---|
531 | URL of Ext JavaScript and resource files (css, images). |
---|
532 | See the documentation for the Ext namespace for details. |
---|
533 | |
---|
534 | The default value is 'ext/' |
---|
535 | --> |
---|
536 | <property name="extBaseURL">ext/</property> |
---|
537 | |
---|
538 | <!-- favicon property |
---|
539 | |
---|
540 | By default, a browser will try to fetch a /favicon.ico icon |
---|
541 | from the root of your web server which is used as an icon |
---|
542 | for your application. You can specify an alternative location |
---|
543 | by setting this property, or for an individual application |
---|
544 | entry point by passing a location to WServer::addEntryPoint(). |
---|
545 | --> |
---|
546 | <!-- <property name="favicon">images/favicon.ico</property> --> |
---|
547 | </properties> |
---|
548 | |
---|
549 | </application-settings> |
---|
550 | |
---|
551 | |
---|
552 | <!-- Override settings for specific applications. |
---|
553 | |
---|
554 | Location refers to physical filesystem location of the |
---|
555 | application. The application prints this location (which |
---|
556 | corresponds to argv[0]) to the log file on startup, and this |
---|
557 | should match exactly. |
---|
558 | --> |
---|
559 | <!-- |
---|
560 | <application-settings |
---|
561 | location="/var/www/localhost/wt-examples/hello.wt"> |
---|
562 | </application-settings> |
---|
563 | --> |
---|
564 | </server> |
---|