Assertion 6.5.6.8 fails, appears to require if-none-match

[PhillipWatts1012]

https://github.com/DMTF/spmf/blob/master/Specification.md
Request Header section
If-None-Match | No | No | RFC 7232

[billdodd]

Can you elaborate on how this assertion is failing for you? (snippet of the log showing the message(s) generated would help)

The request header section quoted indicates that it is not required for the client to send the If-None-Match header. And then for the service behavior, states:

If this HTTP header is present, the service will only return the requested resource if the current ETag of that resource does not match the ETag sent in this header. If the ETag specified in this header matches the resource's current ETag, the status code returned from the GET will be 304.

Looking at the code in the assertion I don't immediately see a problem with the logic (though there may well be one). Just need a better understanding of how it is failing in order to diagnose.

[PhillipWatts1012]

Have a meeting in the morning but then will revisit the assertion. Thanks.?

…

________________________________ From: Bill Dodd <notifications@github.com> Sent: Wednesday, January 3, 2018 4:34 PM To: DMTF/Redfish-Service-Conformance-Check Cc: Watts, John - Dell Team; Author Subject: Re: [DMTF/Redfish-Service-Conformance-Check] Assertion 6.5.6.8 fails, appears to require if-none-match (#61) Can you elaborate on how this assertion is failing for you? (snippet of the log showing the message(s) generated would help) The request header section quoted indicates that it is not required for the client to send the If-None-Match header. And then for the service behavior, states: If this HTTP header is present, the service will only return the requested resource if the current ETag of that resource does not match the ETag sent in this header. If the ETag specified in this header matches the resource's current ETag, the status code returned from the GET will be 304. Looking at the code in the assertion I don't immediately see a problem with the logic (though there may well be one). Just need a better understanding of how it is failing in order to diagnose. - You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#61 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACN_nlvRB9zY_NgnHuM8s5OeW9ZXlThKks5tHABkgaJpZM4RSJ1F>.

[PhillipWatts1012]

Complicated assertion. I'll start with this and research further. ~ GET:/redfish/v1/AccountService/Accounts/rackmanager_oper failed : HTTP status 200:OK, Expected status 304:Not Modified Assertion Description: b'\n304 Not Modified\nThe service has performed a conditional GET request where access is allowed, but the resource content has not changed. Conditional requests are initiated using the headers If-Modified-Since and/or If-None-Match (see HTTP 1.1, sections 14.25 and 14.26) to save network bandwidth if there is no change.\n' <--- Assertion 6.5.6.8: FAIL

…

________________________________ From: Bill Dodd <notifications@github.com> Sent: Wednesday, January 3, 2018 4:34 PM To: DMTF/Redfish-Service-Conformance-Check Cc: Watts, John - Dell Team; Author Subject: Re: [DMTF/Redfish-Service-Conformance-Check] Assertion 6.5.6.8 fails, appears to require if-none-match (#61) Can you elaborate on how this assertion is failing for you? (snippet of the log showing the message(s) generated would help) The request header section quoted indicates that it is not required for the client to send the If-None-Match header. And then for the service behavior, states: If this HTTP header is present, the service will only return the requested resource if the current ETag of that resource does not match the ETag sent in this header. If the ETag specified in this header matches the resource's current ETag, the status code returned from the GET will be 304. Looking at the code in the assertion I don't immediately see a problem with the logic (though there may well be one). Just need a better understanding of how it is failing in order to diagnose. - You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#61 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACN_nlvRB9zY_NgnHuM8s5OeW9ZXlThKks5tHABkgaJpZM4RSJ1F>.

[billdodd]

Thanks, Phillip.

I looked again at the spec and my statement above was incorrect. I said:

The request header section quoted indicates that it is not required for the client to send the If-None-Match header.

The "No" in the "Required" column, of course, means that the server is not required to understand and be able to process the header (in this case the If-None-Match header).

So, you were right, we should not fail the assertion if it returns a 200.

I'll fix that to log a WARN instead. And I also noticed that the assertion incorrectly mentions POST and tests for POST as an allowable operation. I'll clean that up as well.