[441] | 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> |
---|