Stream: hapi
Topic: etags
Jim Steel (Feb 10 2017 at 02:40):
(Related question to my previous one) If I'm writing a resource provider, is it possible to set an ETag on the response I'm providing to a search? Or an operation? And if so, how do I do that?
James Agnew (Feb 11 2017 at 21:04):
The server should automatically set the ETag based on the resource version being returned from a read/vread, but I believe it doesn't set it otherwise.
Jim Steel (Feb 12 2017 at 23:16):
Yeah, I'm implementing a server and hoping to set my own ETags (so I can then respect them if they come back in If-None-Match), to support caching
Grahame Grieve (Feb 13 2017 at 04:46):
not the difference between weak and strong etags. FHIR Etags are *nearly* strong etags, but not actually strong. W3C might have redefined strong etags based on our comments, but it's too late now
James Agnew (Feb 13 2017 at 21:01):
Hmm, interesting..
I'd assume you could achieve this by having your RP methods include parameters of type HttpServletRequest and HttpServletResponse. If you wanted to return a 304 on an arbitrary method, you could create a new exception that extends BaseServerResponseException with a code of 304 and throw that.
I believe this should all work, although I have admittedly not tried it.
Jim Steel (Feb 14 2017 at 23:41):
304 on an arbitrary operation is easy. I just throw a ca.uhn.fhir.rest.server.exceptions.NotModifiedException
James Agnew (Feb 15 2017 at 01:46):
Ah right, I forgot that already existed. :)
So although I haven't seen anyone do it before, what you're doing certainly sounds sensible.. and seems like it should be possible without needing changes to the library.
Jim Steel (Feb 15 2017 at 02:26):
Yeah, I seem to be getting what I need by including request/response as parameters in my RP methods. I'm not sure if the ETags generated for non-reads are things we want to include in the spec. They vary between simple (e.g. for $lookup I'm just using versions of resources, like reads), and not so simple (e.g. $expand or $validate-code)
Jim Steel (Feb 15 2017 at 02:30):
There is a requirement on 304 responses, though, that it should return all the cache-related headers (ETag, Content-Location, Expires, Cache-Control, Vary), that a non-304 response would have returned. I have a vague suspicion that some of these may not be coming through, but when I get to that, if I find any issues I'll flag them on GitHub.
Last updated: Apr 12 2022 at 19:14 UTC
