Wrong error response for HeadObject in s3

[Xuanwo]

    head:
      operationId: HeadObject
      externalDocs:
        url: 'http://docs.amazonwebservices.com/AmazonS3/latest/API/RESTObjectHEAD.html'
      responses:
        '200':
          description: Success
          content:
            text/xml:
              schema:
                $ref: '#/components/schemas/HeadObjectOutput'
        '480':
          description: NoSuchKey
          content:
            text/xml:
              schema:
                $ref: '#/components/schemas/NoSuchKey'

NoSuchKey will be returned in 404 instead of 480, and maybe we don't need to include all error reponses here?

[MikeRalphson]

This appears to be a limitation of AWS's description format, which contains many assumptions and 'magic' rather than being a purely declarative format such as OpenAPI. The shape "NoSuchKey" is not defined and the key "404" appears nowhere in the S3 description file. It doesn't even seem possible to programmatically deduce this from the SDK code.

This is basically a best-effort conversion, I don't have the time to maintain a set of patches on top of the raw conversions, though I might accept them if someone contributed them.

maybe we don't need to include all error responses here?

I'm not sure I understand why we wouldn't include as much information as we can from the input format?

[Xuanwo]

From my point of view (I'm doing some code generation by this spec), an object {} means nothing for me and I have to workaround this by ignore self defined 480 statue code. Instead of expanding this magic to users, maybe eliminate them at specs side is a better solution?

[MikeRalphson]

I'm not convinced. {} is the empty schema and allows everything. Why do you have to remove the dummy error codes? We want to indicate these errors are possible, even if we cannot (yet) map them fully.