Stream: implementers
Topic: X-Request-Id
Grahame Grieve (Nov 09 2017 at 20:51):
The Cerner API marks all responses with an X-Request-Id so they can trace support issues back to their logs. it works really well. But it presents a challenge for me - the level at which I use the request-id is a different one to where I'm handling the HTTP headers... which I think would not be unusual. So I need to track the request-id explicitly... and don't want to have server specific code for this.
Grahame Grieve (Nov 09 2017 at 20:51):
is this something we should standardise?
Jens Villadsen (Nov 09 2017 at 20:53):
as long as it is optional, I would say go for it. It is great for doing your correlation-log-stuff
Jenni Syed (Nov 09 2017 at 21:00):
I think having this at the header level is very important - it's orthogonal to the actual data
Jenni Syed (Nov 09 2017 at 21:03):
In our case, this is often inserted at a different layer - the FHIR server isn't directly aware of it (and this helps troubleshoot when things go wrong before getting to our server)
Keith Boone (Nov 09 2017 at 21:04):
I'm with Jenni on this. In HTTP we see this in headers, in SOAP, in the envelope, in SMTP also in headers. It's tracking data. IF it gets into the resource, it becomes a problematic to deal with.
Grahame Grieve (Nov 09 2017 at 21:16):
umm, I mean, standardise the name of the header in the http. Definitely not something to put in a resource
Grahame Grieve (Nov 09 2017 at 21:47):
@John Moehrke I'm not sure where this field goes in AuditEvent, btw
John Moehrke (Nov 09 2017 at 23:12):
It isn't an active participant (agent), so I would put this into an AuditEvent.entity. it would likely just put the valu of X-Request-Id into AuditEvent.entity.name and set AuditEvent.entity.type to "X-Request-Id". Very little overhead, but easy to search/match. I was expecting to find something like this in IHE for SOAP request identifiers...
Grahame Grieve (Nov 09 2017 at 23:21):
I didn't think of that because I don't see the log id is 'data or objects used'
Kevin Mayfield (Nov 10 2017 at 10:41):
We've started to look at this and are using this within our reference implementation. We are putting a correlation Id in X-Request-Id header and responses it's going in X-Correlation-Id.
Kevin Mayfield (Nov 10 2017 at 10:44):
We're thinking it needs to be standardised (along with X-Forwarded-For and X-Forwarded-Host) for gateways.
Kevin Mayfield (Nov 10 2017 at 10:44):
(the 'we' means our team, not project or organisation)
Grahame Grieve (Nov 10 2017 at 21:32):
Nick Hatt (Nov 13 2017 at 16:31):
Maybe name it without an X-? fhir-request-id? https://tools.ietf.org/html/rfc6648
Grahame Grieve (Nov 14 2017 at 01:07):
interesting. I had not seen that
John Moehrke (Nov 14 2017 at 15:46):
FYI: I wrote this up in a blog... that is the impact on AuditEvent record https://healthcaresecprivacy.blogspot.com/2017/11/extra-softwaretransaction-details-in.html
Kevin Mayfield (Nov 14 2017 at 15:53):
thanks. That link is very useful
Grahame Grieve (Jul 20 2018 at 02:14):
ok actioned task GF#14162. But it was short on details, so I'm looking for review of what I wrote. see build.fhir.org/http.html#custom. @John Moehrke @Nick Hatt @Kevin Mayfield @Jenni Syed @Paul Knapp @Brian Pech @Andy Stechishin
Lloyd McKenzie (Jul 20 2018 at 02:22):
That anchor doesn't resolve
Grahame Grieve (Jul 20 2018 at 02:37):
will soon. give it a little while to build...
John Moehrke (Jul 20 2018 at 18:11):
did you move that audit to another task?
Grahame Grieve (Jul 20 2018 at 20:15):
no I didn't do that
Brian Postlethwaite (Mar 22 2019 at 06:04):
I'm re-looking into this now (while implementing a form of gateway) and notices that the x-forwarded-host seems a little strange,
Is this meant to have the full URL of the request, just the base URL of the FHIR server for the request, or just the hostname of the request (which isn't going to be enough to work out what it was)
e.g.
apigatewayserver.example.com
http://apigatewayserver.example.com/fhirserver2
http://apigatewayserver.example.com/fhirserver2/Patient/45/_history/2
http://apigatewayserver.example.com/fhirserver1/Practitioner?active=true
(p.s. I'm really hoping its the latter of the formats, not the first one.
Michael Lawley (Mar 22 2019 at 07:17):
Indeed - the first one won't even tell you http vs https (ouch)
Grahame Grieve (Mar 22 2019 at 21:09):
it would just be the FQDN of the server
Grahame Grieve (Mar 22 2019 at 21:09):
why would that not be enough? enough for what?
Michael Lawley (Mar 22 2019 at 23:25):
Generally you want this sort of think for constructing URLs in responses that reference the external-facing endpoint rather than the internal deployment endpoint.
Grahame Grieve (Mar 22 2019 at 23:34):
how would that be solved elsewhere?
Brian Postlethwaite (Mar 23 2019 at 03:27):
I was about to put in a setting for what the external base url is for the server so that when generating absolute urls they are created right.
Relative urls don't have the problem, which I would suspect most Web apps do.
Michael Lawley (Mar 23 2019 at 03:36):
Yep. Ontoserver uses a setting, but that is limiting in some cases, and not as good as "it just works".
Relative links is generally fine for Web Apps, but not for FHIR Resources that require absolute URLs
Brian Postlethwaite (Mar 25 2019 at 00:44):
After more research over the weekend, this is just the hostname, nothing further - as per the standard HTTP stuff
But we have missed X-Forwarded-Proto and X-Forwarded-Port which are not covered, and probably should be included.
Grahame Grieve (Mar 25 2019 at 02:09):
are these used elsewhere?
Brian Postlethwaite (Mar 25 2019 at 08:36):
It's the full set of related headers. And many proxies set these.
Michael Lawley (Mar 28 2019 at 11:43):
And then there's the Forwarded header, which is the standardised one: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded -- does it need to be included as well?
Grahame Grieve (Mar 28 2019 at 18:34):
well, we don't need to define it then
John Moehrke (Sep 06 2019 at 15:28):
has anyone started to log the X-Request-Id in their AuditEvent logs? If so, how do you encode it.. might be something useful to standardsize? Or at least provide an example?
Grahame Grieve (Sep 06 2019 at 20:07):
"entity" : [{ "type" : { "code" : "X-Request-Id"}, "identifier" : { "value" : "[v]"} }]
Grahame Grieve (Sep 06 2019 at 20:07):
that's what I'm doing. I think there's a couple of problems with that
Last updated: Apr 12 2022 at 19:14 UTC
