search

DMTF / Redfish-Service-Conformance-Check

This tool checks an operational Redfish Service to see that it conforms to the normative statements from the Redfish specification
Other
4 stars 8 forks source link

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

Closed PhillipWatts1012 closed 6 years ago

PhillipWatts1012 commented 6 years ago

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

billdodd commented 6 years ago

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 commented 6 years ago

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 GitHubhttps://github.com/DMTF/Redfish-Service-Conformance-Check/issues/61#issuecomment-355146953, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACN_nlvRB9zY_NgnHuM8s5OeW9ZXlThKks5tHABkgaJpZM4RSJ1F.

PhillipWatts1012 commented 6 years ago

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 GitHubhttps://github.com/DMTF/Redfish-Service-Conformance-Check/issues/61#issuecomment-355146953, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACN_nlvRB9zY_NgnHuM8s5OeW9ZXlThKks5tHABkgaJpZM4RSJ1F.

billdodd commented 6 years ago

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.