Page History
...
| Property name | Default value | Description |
|---|---|---|
| Incoming request processing | ||
request.timestamp.enabled | false | Whether or not the timestamp of an incoming request should be verified. The expiration time is included in the message |
request.timestamp.max-clock-skew | 300 | Maximum number of seconds the clock of the other system is allowed to derive deviate from the receiving system. Introduced in Blueriq 18.6.1. In Blueriq 18.6.0, the value would always be 0, which was likely to might cause problems when clocks are not exactly synchronized. |
request.timestamp.max-ttl | 300 | Maximum time to live: maximum allowed number of seconds between the message's created and expires timestamp. If this number is greater than the specified max ttl, it is rejected. Introduced in Blueriq 18.6.1. In Blueriq 18.6.0, the value would always be 300. |
| Outgoing response processing | ||
response.timestamp.enabled | false | Indicates whether a creation and expiration timestamp will be added to the response. |
request.timestamp.ttl | 300 | Time to live: maximum number of seconds that may have passed since the message's created timestamp. If the message is older, it should be rejected by the receiver. |
...
| Property name | Default value | Description |
|---|---|---|
| Outgoing request processing | ||
request.timestamp.enabled | false | Indicates whether a creation and expiration timestamp will be added to the request. |
response.timestamp.ttl | 300 | Time to live: maximum number of seconds that may have passed since the message's created timestamp. If the message is older, it should be rejected by the receiver. |
| Incoming response processing | ||
response.timestamp.enabled | false | Indicates whether the creation and expiration timestamp should be verified. |
response.timestamp.max-clock-skew | 300 | Maximum number of seconds the clock of the other system is allowed to derive deviate from the receiving system. Introduced in Blueriq 18.6.1. In Blueriq 18.6.0, the value would always be 0, which was likely to might cause problems when clocks are not exactly synchronized. |
response.timestamp.max-ttl | 300 | Maximum time to live: maximum allowed number of seconds between the message's created and expires timestamp. If this number is greater than the specified max ttl, it is rejected. Introduced in Blueriq 18.6.1. In Blueriq 18.6.0, the value would always be 300. |
...
Overview
Content Tools