New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server Side ETAG no longer being returned 3.1.0 #808

Closed
Chrisjobling opened this Issue Dec 20, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@Chrisjobling

Chrisjobling commented Dec 20, 2017

After upgrading HapiFhir to version 3 from 2, Etags from the server are no longer automatically being returned. The setETagSupport() seems to have no impact. Is there any advice as to get the server to respond with the Etags again
Thanks

@jamesagnew

This comment has been minimized.

Owner

jamesagnew commented Dec 20, 2017

Can you provide a bit more detail about what you are doing? ETags look ok to me (note the 3rd last header below)

 curl -v http://fhirtest.uhn.ca/baseDstu3/Patient/191025                                                      0 < 06:31:15
*   Trying 34.196.9.98...
* TCP_NODELAY set
* Connected to fhirtest.uhn.ca (34.196.9.98) port 80 (#0)
> GET /baseDstu3/Patient/191025 HTTP/1.1
> Host: fhirtest.uhn.ca
> User-Agent: curl/7.55.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx/1.10.3 (Ubuntu)
< Date: Wed, 20 Dec 2017 11:31:15 GMT
< Content-Type: application/fhir+json;charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< X-Powered-By: HAPI FHIR 3.1.0 REST Server (FHIR Server; FHIR 3.0.1/DSTU3)
< ETag: W/"9"
< Last-Modified: Fri, 15 Dec 2017 06:34:10 GMT
< Location: http://fhirtest.uhn.ca/baseDstu3/Patient/191025/_history/9
< 
{
  "resourceType": "Patient",
  "id": "191025",
  "meta": {
    "versionId": "9",
    "lastUpdated": "2017-12-15T01:34:10.319-05:00"
  },
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><div class=\"hapiHeaderText\">Keira1</div><table class=\"hapiPropertyTable\"><tbody><tr><td>Identifier</td><td>12345</td></tr></tbody></table></div>"
  },
  "identifier": [
@Chrisjobling

This comment has been minimized.

Chrisjobling commented Dec 20, 2017

We have a server implementation and are running automated tests against this implementation. A simple test example is "Read a patients single appointment" where previously an Etag was returned upon the read. I am setting the meta version ID of the appointment and ever since the upgrade from version 2 to 3 the Etag is no longer being returned. I am just wondering if it is to do with the Type changes from the upgrade or if there is something that needs to be added to respond with the Etags. I have read the documentation but am currently unable to get it included in the response.

Example response:

HTTP/1.1 200
Cache-Control: no-store
X-Powered-By: HAPI FHIR 3.0.0 REST Server (FHIR Server; FHIR 3.0.1/DSTU3)
Last-Modified: Wed, 20 Dec 2017 12:25:24 GMT
Location: "http://ans-a:19191/fhir/Appointment/1"
Content-Type: application/json+fhir;charset=UTF-8
Date: Wed, 20 Dec 2017 12:25:24 GMT
Content-Length: 1290

{"resourceType":"Appointment","id":"1","meta":{"versionId":"1","lastUpdated":"2017-12-20T12:25:24.000+00:00",

Any help would be appriciated
Thanks

@Chrisjobling

This comment has been minimized.

Chrisjobling commented Dec 20, 2017

HTTP/1.1 200
Cache-Control: no-cache, no-store
Expires: 0
Pragma: no-cache
X-Powered-By: HAPI FHIR 3.0.0 REST Server (FHIR Server; FHIR 1.0.2/DSTU2)
ETag: W/"1469444400000"
Content-Location: http://ans-a357:19191/fhir/Patient/1/_history/1469444400000
Last-Modified: Mon, 25 Jul 2016 11:00:00 GMT
Location: http://ans-a357:19191/fhir/Patient/1/_history/1469444400000
Content-Type: application/json+fhir;charset=UTF-8
Date: Wed, 20 Dec 2017 15:57:05 GMT
Content-Length: 1198

Just for reference this is the response when running the version with FHIR 1.0.2/DSTU2.

@jamesagnew

This comment has been minimized.

Owner

jamesagnew commented Dec 20, 2017

@haydenanswer

This comment has been minimized.

haydenanswer commented Jan 2, 2018

Just to update you on this issue...

The line you suggested for the breakpoint above revealed that fullId.hasVersionIdPart() was false.

Now, in addition to moving from 2.x to 3.0.0, we also updated our server implementation from DSTU2 to STU3.

It seems that the DSTU2 structures and STU3 structures differ when setting the Metadata VersionId.

For example, in our implementation we had the following:

resource.getMeta().setVersionId(versionId);

In the DSTU2 structures, the call to getMeta() returns an IBaseMetaType, the implementation of which is contained within the resource . The implementation of setVersionId actually updates the id on the BaseResource (making the call to fullId.hasVersionIdPart() == true)

In contrast, in the STU3 structures the call to getMeta() returns a Meta (which is entirely seperate to the BaseResource).

Our solution so far has been to just set the BaseResource Id VersionId in addition to setting the BaseResource Meta VersionId - this feels a little hacky however.

@jamesagnew

This comment has been minimized.

Owner

jamesagnew commented Jan 8, 2018

Ah, that makes sense. I'll update to look at the resource getMeta() version if the ID itself doesn't have one. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment