tballison commented on PR #3519:
URL: https://github.com/apache/tika/pull/3519#issuecomment-6639221544
Only nits from by :robot: . Let me know what you think
```
Edge cases (worth fixing):
1. An option silently cancels a setting in Docker. The Docker entrypoint
always passes -h 0.0.0.0. So
TIKA_SERVER_SETTING_HOST=127.0.0.1 is logged as "set by
TIKA_SERVER_SETTING_HOST", and then -h replaces it with
no message. My probe got host=0.0.0.0. The same happens with PORT
against -p, ID against -i and METRICS_PORT
against --metricsPort. A user who tries to narrow the bind address gets
the wider one. Cheapest fix: fail at
startup, or at least warn, when an option and a setting name the same
field.
2. Text values are mangled. The PR converts any value that looks like a
number into a number before binding, so
TIKA_SERVER_SETTING_ID=007 becomes id 7, and the same would happen with
cors or host. Passing every value as a
plain string fixes this: Jackson already converts strings to long and
boolean. My probes showed it rejects "1.5"
for an int field and accepts "TRUE". That also removes the valueNode
helper and its 18-digit regex.
3. Two variables can name the same field. ALLOW_PIPES and ALLOW__PIPES
both become allowPipes. The first one read
wins, and the environment's order isn't defined, so which value applies
is arbitrary and nothing says so. Fix:
refuse two sources for the same field at the same level.
4. TIKA_SERVER_SETTING_PRESETS is accepted and then thrown away. Startup
succeeds and the presets list is empty. It
should be refused with a pointer to TIKA_PRESETS, the way configPath is
already refused with a pointer to -c.
Minor clean-ups:
- The PR title and the first commit message still say TIKA_SERVER_<FIELD>.
A squash merge would put the wrong
variable name in the history.
- The server docs open with "Every field can also be set", then exclude
tlsConfig and endpoints a few lines later.
Saying "every field except tlsConfig and endpoints" up front would be
clearer.
```
--
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]
