usnistgov / ACVP-Server

A repository tracking releases of NIST's ACVP server. See www.github.com/usnistgov/ACVP for the protocol.
46 stars 16 forks source link

HTTP Status Code 413 Returned from Server #235

Closed powersmc closed 1 year ago

powersmc commented 1 year ago

environment Prod

testSessionId 16406

vsId 177194

Algorithm registration

{
            "algorithm":"kdf-components",
            "revision":"1.0",
            "mode":"ikev2",
            "capabilities":[
               {
                  "authenticationMethod":"dsa",
                  "hashAlg":[
                     "SHA-1",
                     "SHA2-224",
                     "SHA2-256",
                     "SHA2-384",
                     "SHA2-512"
                  ],
                  "initiatorNonceLength":[
                     {
                        "min":64,
                        "max":2048,
                        "increment":8
                     }
                  ],
                  "responderNonceLength":[
                     {
                        "min":64,
                        "max":2048,
                        "increment":8
                     }
                  ],
                  "diffieHellmanSharedSecretLength":[
                     {
                        "min":224,
                        "max":8192,
                        "increment":8
                     }
                  ],
                  "derivedKeyingMaterialLength":[
                     {
                        "min":160,
                        "max":16384,
                        "increment":8
                     }
                  ]
               },

Endpoint in which the error is experienced /acvp/v1/testSessions/16406/vectorSets/177194 POST

Expected behavior The expected behavior here is just that the server would accept our POST request. The server is, however, returning a 413 error code and providing the error message "The page was not displayed because the request entity is too large". The response JSON we're attempting to submit is fairly large (32,120,761 bytes) - the issue just seems to be that we're hitting some upper limit that's configured server-side.

What I'm trying to determine here is whether:

  1. This is the intended behavior, and we should be breaking up the response into smaller chunks -or-
  2. This is unintended behavior, and the server just needs to be re-configured to increase the request size limit

Additional context If we're expected to break up the response into smaller chunks, my question then would just be how we should go about doing that. Is it permittable to submit partial results? For example - if there are 45 tgIds, could we submit results for just 20 of them at a time? Or would the server mark the 25 that have not been submitted yet as failing and prevent subsequent submissions?

livebe01 commented 1 year ago

Thanks for letting us know about this @powersmc. This should be fixed now. Can you retry?

powersmc commented 1 year ago

Yup, it appears to be fixed now. Thanks!