Home
last modified time | relevance | path

Searched hist:"2 d6cb56b6b47c3fbb0d234ade5c1208edb69ef1f" (Results 1 – 5 of 5) sorted by relevance

/openbmc/bmcweb/redfish-core/include/
H A Dquery.hppdiff a1cbc1920833ae7f7cf9c2e7df06e37dc7f9f530 Wed Mar 29 02:24:42 CDT 2023 Hieu Huynh <hieuh@os.amperecomputing.com> Fix If Match header in Http layer

Commit [1] prevents the clients performing methods if missing ETag
from the If-Match header.
For the "If-Match: *" [2] that representing any resource, it should
be the valid command.

[1] https://github.com/openbmc/bmcweb/commit/2d6cb56b6b47c3fbb0d234ade5c1208edb69ef1f
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match

Tested:
Can performing methods GET/POST/PATCH/DELETE with "If-Match: *"
header.

Signed-off-by: Hieu Huynh <hieuh@os.amperecomputing.com>
Change-Id: I2e5a81ed33336a939b01bd6b64d3ff99501341d0
diff 2d6cb56b6b47c3fbb0d234ade5c1208edb69ef1f 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/http/
H A Dhttp_request.hppdiff 2d6cb56b6b47c3fbb0d234ade5c1208edb69ef1f 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 Dhttp_response.hppdiff 2d6cb56b6b47c3fbb0d234ade5c1208edb69ef1f 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 Drouting.hppdiff 2d6cb56b6b47c3fbb0d234ade5c1208edb69ef1f 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 Dhttp_connection.hppdiff 5ae6f9254161f7229216c08b591e31eaf10f69e4 Mon Jan 09 12:45:53 CST 2023 Ed Tanous <edtanous@google.com> Fix keepalive false

When we changed [1] to using a std::move of the Request object instead
of an unsafe reference, we missed one spot where we were using the
request object, post handle. This commit moves the keepalive function
to be set on the response object before calling handle.

Tested:
curl request with -H "Connection: close", -H "Connection: keep-alive"
and no header all return the correct values.

[1] 2d6cb56b6b47c3fbb0d234ade5c1208edb69ef1f

Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I91fe32162407f1e1bdfcc06f1751e02d11f8a697