|
|
Post by AMI_Mani on Aug 5, 2022 14:49:29 GMT
Hi,
Do we need to support Transfer encoding Chunked as mandatory or optional for Redfish? I'm unable to see any details about this in Redfish specification(DSP0266_1.15.0.pdf) mentioned for Request header, Response header sections
In Status code section of Redfish specification (DSP0266_1.15.0.pdf)we have below information
Redfish services should not return the HTTP 100 status code. Using the HTTP protocol for a multipass data
transfer should be avoided, except for the upload of extremely large data
Can we use HTTP 100 status code for supporting Transfer encoding Chunked or we should not support HTTP 100 status code for Redfish implementation?
Since Redfish is mostly Rest api request, response chunked data transfer is not required except for file upload operation, please add input of using chunked data transfer for normal post, patch operations
Thanks,
Mani
|
|
|
|
Post by mraineri on Aug 5, 2022 15:27:37 GMT
Since we do not specify the header in the table, it's not mandatory. You can certainly reject requests from clients that attempt to chunk requests.
If you need to support accepting chunked requests from clients, then that seems like a case where you may need to use HTTP 100 Continue (but it might not be necessary depending on how fast the client sends each chunk). Outside of this, I don't see a need for HTTP 100 Continue. Keep in mind, the recommendation to not use HTTP 100 Continue is a "should" in the spec, meaning you can use it if you need to, but consider avoiding it if possible. As far as I can tell, chunking might be the only place where HTTP 100 Continue is a real possibility; I can't think of other cases where it would ever be needed.
|
|
|
|
Post by Abner Chang on Jan 14, 2023 7:50:36 GMT
"Redfish services should not return the HTTP 100 status code. Using the HTTP protocol for a multipass data
transfer should be avoided, except for the upload of extremely large data"
HTTP 100 could be used for below two reasons:
1. The huge payload (e.g., BIOS AttributeRegistry, my previous company has the mass payload that is sent using chunk):
2. Check if the HTTP method is supported on the particular URI.
The confirmation of the above behaviors can be accomplished by HTTP header "Expect" and 100-continue.
Do we need support Transfer encoding Chunked? If you are using in-house OEM SFW/BMC FW, then you can decide whether to use Chunk or not. That is the agreement between proprietary SFW/BMC FW implementations.
However, from opensource SFW viewpoint, we should be able to programmatically handle the mass payload and unsupported HTTP method flexibly. So we can have better error handling. SFW uses "Expect" to probe if the service can accept the HTTP request prior to sending a huge payload and then get the "413 Paylaod too large" error in the end, or "405 method not allowed" if SFW patches the resource however the write request on that URI is restricted by BMC.
I think "should not" is too restricted because opensource SFW needs an efficient way to communicate with service and a generic solution that can flexibly work on BMC firmwares. It would be better if the spec says "Redfish services can optionally support Expect and return the HTTP 100 status code...". We can also have a build option to enable sending "Expect" or not in Opensource SFW.
|
|
|
|
Post by mraineri on Jan 18, 2023 16:30:31 GMT
I've been looking even further into chunking and the usage of HTTP 100 and it looks like I was incorrect about the usage; to send a chunked request body, you don't need to rely on the server sending back 100 Continue. The usage I see with 100 Continue is where the client will first send the HTTP headers, but wants an acknowledgement back that the service will be able to accept the incoming body; you can perform chunked requests without this.
For your two cases:
1) You should be able to perform chunking without the need for 100 Continue.
2) You can inspect the Allow response header from a HEAD or GET request.
|
|
|
|
Post by Abner Chang on Jan 19, 2023 1:46:55 GMT
However, Expect-Continue is the way to determine whether to chunk the payload or not according to "413 Paylaod too large". It is not necessary to chunk the payload into multiple transfers if the service can handle the big payload at once.
|
|
