Willy,
Am 19.03.2018 um 21:47 schrieb Willy Tarreau:
> Simply because unique-id was created many years before the extensible
> log-format ou know today existed, and that apparently nobody felt the
> need to port it. It may be as simple as creating a few sample fetches,
> I don't know.
This was more of a rhetorical question. It looks like that the unique ID
is handled somewhat differently in the processing (just like the
redirects are). I mentioned it because it possibly is related. Here's an
example configuration:
> global
> stats timeout 30s
>
> defaults
> log global
> timeout connect 5s
> timeout client 50s
> timeout server 50s
> unique-id-format %{+X}o\ REQ-%Ts%rt
>
> frontend fe_http
> mode http
>
> bind :::8080 v4v6
>
> unique-id-header X-Req-ID1
> http-request set-header X-Req-ID2 %ID
> http-response set-header X-Req-ID %ID
>
> use_backend bk_example
>
> backend bk_example
> mode http
>
> http-request set-header Host postb.in
> server example postb.in:80
I feel like X-Req-ID1 and X-Req-ID2 should have the same value for the
upstream service, yet X-Req-ID2 is *empty* for `http-request set-header`
and works fine for `http-response set-header`. This does not look like
missing fetches, but rather like the ID being generated *after*
http-request set-header already has been processed.
> I really think it's where we need to invest more thoughts. At least you
> provided two use cases and that shows that a single header directive
> might not be enough, and that HSTS definitely isn't a special case at
> all.
>
Here's two more that came into my mind:
- Expect-CT
- Public-Key-Pins (a.k.a. HPKP)
Both are deeply related to HSTS due do being TLS security headers. The
latter is being deprecated by the browsers, because of footgun issues,
though. The former is fairly new.
Best regards
Tim Düsterhus
