On Mon, Mar 19, 2018 at 10:04:25PM +0100, Tim Düsterhus wrote:
> 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.
Looks like it indeed. By then there was no "http-request" ruleset
either. Maybe we could move it to a place where it's generated
earlier, or maybe we could ensure that it's computed on the fly
when the associated sample fetch function is called for %ID (I
didn't remember it was available like this).
> > 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.
Yes it's still a draft (unless I missed the announce).
Thanks for your inputs.
Willy
