You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It does not currently seem possible to be able to make a HTTP range request for an endpoint that returns a binary asset (i.e., not a JSON-formatted response). I believe we would need the following things:
some way to add a Range header with a value like bytes=1000-4999 (representing a request for 4000 bytes starting at offset 1000) on a request as part of building it
to accept either a HTTP 200 OKor a HTTP 206 Partial Content response in the case of a range request
to provide a useful error in the case that we get a HTTP 416 Range Not Satisfiable response
to expose the value of the Content-Range header in the response to the consumer so that we can confirm that the server understood our range request
to expose the value of the Aceept-Ranges header from the response to a GET or (especially) HEAD request, so that a client can determine if the server is reporting range request support
I couldn't immediately find a way for an OpenAPI definition document to report support for range requests, so it would be up to the consumer and the server to correctly negotiate them using the regular pattern of headers and HEAD requests.
The text was updated successfully, but these errors were encountered:
I think I'd expect range headers to appear in the OpenAPI description of the operation. If they existed, I'd expect progenitor to emit code to let you specify them. I know we may resolve your proximate need with #750, but there may be dropshot facilities we could build for a more robust binary asset response.
It does not currently seem possible to be able to make a HTTP range request for an endpoint that returns a binary asset (i.e., not a JSON-formatted response). I believe we would need the following things:
I couldn't immediately find a way for an OpenAPI definition document to report support for range requests, so it would be up to the consumer and the server to correctly negotiate them using the regular pattern of headers and HEAD requests.
The text was updated successfully, but these errors were encountered: