moonchen opened a new issue, #13288:
URL: https://github.com/apache/trafficserver/issues/13288
### Summary
The documentation for `proxy.config.ssl.max_record_size` states that a value
of `-1`
enables dynamic TLS record sizing. In practice the setting cannot be given
that value:
configuration validation only accepts `0`–`16383`, so `-1` is rejected at
startup and
the feature cannot be enabled through `records.yaml`.
### Steps to reproduce
1. In `records.yaml`, set:
```yaml
records:
ssl:
max_record_size: -1
```
2. Start Traffic Server and check `traffic.out`.
### Expected behavior
Per the documentation, the value is accepted and Traffic Server uses dynamic
record
sizing (small records for roughly the first 1 MB of a response, then 16 KB
records
afterward).
### Actual behavior
Traffic Server rejects the value with a warning and falls back to the
default (`0`,
which writes all available data into a single record):
```
WARNING: proxy.config.ssl.max_record_size - Validity Check error at line=7,
col=5. Pattern '[0-16383]' failed against '-1'. Default value will be used
```
Dynamic record sizing is therefore unreachable from configuration, even
though the
supporting code is present.
### Root cause
The record definition in `src/records/RecordsConfig.cc` constrains the value
to
`[0-16383]`, which excludes the documented sentinel `-1`:
```c
{RECT_CONFIG, "proxy.config.ssl.max_record_size", RECD_INT, "0",
RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-16383]", RECA_NULL}
```
The documentation (`doc/admin-guide/files/records.yaml.en.rst`) is also
internally
inconsistent: it first says the value may be "between 0 and 16383," then
separately
documents `-1` for dynamic sizing.
### Suggested fix
Decide which behavior is intended and make the code and docs agree:
- If dynamic sizing is supported: widen the validation to also accept `-1`,
and state
the allowed values consistently as `-1`, `0`, or `1`–`16383`.
- If it is no longer supported: remove the `-1` description from the
documentation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]