Searched hist:"2 d6cb56b" (Results 1 – 4 of 4) sorted by relevance
| /openbmc/bmcweb/http/ |
| H A D | http_request.hpp | 2d6cb56b Thu Jul 07 22:44:54 CDT 2022 Ed Tanous <edtanous@google.com> Implement If-Match header in Http layer
If-Match is a header in the HTTP specification[1] designed for handling
atomic operations within a given HTTP tree. It allows a mechanism for
an implementation to explicitly declare "only take this action if the
resource has not been changed". While most things within the Redfish
tree don't require this level of interlocking, it continues to round out
our redfish support for the specific use cases that might require it.
Redfish specification 6.5 states:
If a service supports the return of the ETag header on a resource, the
service may respond with HTTP 428 status code if the If-Match or
If-None-Match header is missing from the PUT or PATCH request for the
same resource, as specified in RFC6585
This commit implements that behavior for all handlers to follow the
following flow.
If If-Match is present
Repeat the same request as a GET
Compare the ETag produced by the GET, to the one provided by If-Match
If they don't match, return 428
if they do match, re-run the query.
[1] https://www.rfc-editor.org/rfc/rfc2616#section-14.24
As a consequence, this requires declaring copy and move constructors
onto the Request object, so the request object can have its lifetime
extended through a request, which is very uncommon.
Tested:
Tests run on /redfish/v1/AccountService/Accounts/root
PATCH with correct If-Match returns 200 success
PATCH with an incorrect If-Match returns 419 precondition required
GET returns the resource as expected
Redfish service validator passes
Redfish protocol validator passes! ! ! ! !
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I530ab255259c32fe4402eb8e5104bd091925c77b
|
| H A D | http_response.hpp | 2d6cb56b Thu Jul 07 22:44:54 CDT 2022 Ed Tanous <edtanous@google.com> Implement If-Match header in Http layer
If-Match is a header in the HTTP specification[1] designed for handling
atomic operations within a given HTTP tree. It allows a mechanism for
an implementation to explicitly declare "only take this action if the
resource has not been changed". While most things within the Redfish
tree don't require this level of interlocking, it continues to round out
our redfish support for the specific use cases that might require it.
Redfish specification 6.5 states:
If a service supports the return of the ETag header on a resource, the
service may respond with HTTP 428 status code if the If-Match or
If-None-Match header is missing from the PUT or PATCH request for the
same resource, as specified in RFC6585
This commit implements that behavior for all handlers to follow the
following flow.
If If-Match is present
Repeat the same request as a GET
Compare the ETag produced by the GET, to the one provided by If-Match
If they don't match, return 428
if they do match, re-run the query.
[1] https://www.rfc-editor.org/rfc/rfc2616#section-14.24
As a consequence, this requires declaring copy and move constructors
onto the Request object, so the request object can have its lifetime
extended through a request, which is very uncommon.
Tested:
Tests run on /redfish/v1/AccountService/Accounts/root
PATCH with correct If-Match returns 200 success
PATCH with an incorrect If-Match returns 419 precondition required
GET returns the resource as expected
Redfish service validator passes
Redfish protocol validator passes! ! ! ! !
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I530ab255259c32fe4402eb8e5104bd091925c77b
|
| H A D | routing.hpp | 2d6cb56b Thu Jul 07 22:44:54 CDT 2022 Ed Tanous <edtanous@google.com> Implement If-Match header in Http layer
If-Match is a header in the HTTP specification[1] designed for handling
atomic operations within a given HTTP tree. It allows a mechanism for
an implementation to explicitly declare "only take this action if the
resource has not been changed". While most things within the Redfish
tree don't require this level of interlocking, it continues to round out
our redfish support for the specific use cases that might require it.
Redfish specification 6.5 states:
If a service supports the return of the ETag header on a resource, the
service may respond with HTTP 428 status code if the If-Match or
If-None-Match header is missing from the PUT or PATCH request for the
same resource, as specified in RFC6585
This commit implements that behavior for all handlers to follow the
following flow.
If If-Match is present
Repeat the same request as a GET
Compare the ETag produced by the GET, to the one provided by If-Match
If they don't match, return 428
if they do match, re-run the query.
[1] https://www.rfc-editor.org/rfc/rfc2616#section-14.24
As a consequence, this requires declaring copy and move constructors
onto the Request object, so the request object can have its lifetime
extended through a request, which is very uncommon.
Tested:
Tests run on /redfish/v1/AccountService/Accounts/root
PATCH with correct If-Match returns 200 success
PATCH with an incorrect If-Match returns 419 precondition required
GET returns the resource as expected
Redfish service validator passes
Redfish protocol validator passes! ! ! ! !
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I530ab255259c32fe4402eb8e5104bd091925c77b
|
| /openbmc/bmcweb/redfish-core/include/ |
| H A D | query.hpp | 2d6cb56b Thu Jul 07 22:44:54 CDT 2022 Ed Tanous <edtanous@google.com> Implement If-Match header in Http layer
If-Match is a header in the HTTP specification[1] designed for handling
atomic operations within a given HTTP tree. It allows a mechanism for
an implementation to explicitly declare "only take this action if the
resource has not been changed". While most things within the Redfish
tree don't require this level of interlocking, it continues to round out
our redfish support for the specific use cases that might require it.
Redfish specification 6.5 states:
If a service supports the return of the ETag header on a resource, the
service may respond with HTTP 428 status code if the If-Match or
If-None-Match header is missing from the PUT or PATCH request for the
same resource, as specified in RFC6585
This commit implements that behavior for all handlers to follow the
following flow.
If If-Match is present
Repeat the same request as a GET
Compare the ETag produced by the GET, to the one provided by If-Match
If they don't match, return 428
if they do match, re-run the query.
[1] https://www.rfc-editor.org/rfc/rfc2616#section-14.24
As a consequence, this requires declaring copy and move constructors
onto the Request object, so the request object can have its lifetime
extended through a request, which is very uncommon.
Tested:
Tests run on /redfish/v1/AccountService/Accounts/root
PATCH with correct If-Match returns 200 success
PATCH with an incorrect If-Match returns 419 precondition required
GET returns the resource as expected
Redfish service validator passes
Redfish protocol validator passes! ! ! ! !
Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I530ab255259c32fe4402eb8e5104bd091925c77b
|