Will the mock response support octet-stream?

[Celthi]

I have an endpoint that will return a octet-stream as follows, but the response will be json instead of octet-stream

      responses:
        "200":
          description: The requested properties are successfully returned.
          content:
            application/octet-stream:
              schema:
                type: string
                format: binary
                x-content-type: application/octet-stream
                example:   # Sample object
                  externalValue: '/Users/xxx/Downloads/nodejs-server-mock2/README.md'

With the above schema, the response is

curl -v -X GET "http://localhost:5000/api/objects" -H "accept: application/octet-stream" -H "X: fasdfa"
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 5000 (#0)
> GET /api/objects HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.64.1
> accept: application/octet-stream
> X-MSTR-ISERVER-SESSION: fasdfa
> 
< HTTP/1.1 200 OK
< x-powered-by: jormaechea/open-api-mock
< Vary: Origin
< Access-Control-Allow-Credentials: true
< Content-Type: application/json; charset=utf-8
< Content-Length: 72
< ETag: W/"48-moCYJiPDoNqlzQ7AhOmaHZSX3cU"
< Date: Tue, 20 Apr 2021 00:52:10 GMT
< Connection: keep-alive
< 
* Connection #0 to host localhost left intact
{"externalValue":"/Users/xxx/Downloads/nodejs-server-mock2/README.md"}* Closing connection 0

[Celthi]

If I commented out the example above, the response will be

* Connected to localhost (::1) port 5000 (#0)
> GET /api/objects HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.64.1
> accept: application/octet-stream
> X-MSTR-ISERVER-SESSION: fasdfa
> 
< HTTP/1.1 200 OK
< x-powered-by: jormaechea/open-api-mock
< Vary: Origin
< Access-Control-Allow-Credentials: true
< Content-Type: application/json; charset=utf-8
< Content-Length: 8
< ETag: W/"8-r11mbMxk38LLcw6NaqQZHEqTW1U"
< Date: Tue, 20 Apr 2021 01:11:40 GMT
< Connection: keep-alive
< 
* Connection #0 to host localhost left intact
"string"* Closing connection 0

[Celthi]

So both will return < Content-Type: application/json; charset=utf-8 instead of octet-stream

[jormaechea]

I think we have two problems here:

• The externalValue property is not supported yet. If you want that, I recommend to open a separate issue for it.
• We're not handling the response content-type properly.

For the second problem I think that we have to make two improvements:

1. Get the media-type from the response object and format the API response according to it.
2. Add support for the Accept HTTP header to select the proper response (or respond with a 415 Unsupported Media Type if it's not defined in the schema)

Relevant documentations:

• Express.js response type
• @hapy/accept mediaType

[Celthi]

Thanks. I'll try to see if I can make the enhancement

[jormaechea]

Hi @Celthi any updates on this? If you don't have time for it maybe someone else can take care..
Just let me know 😉

[Celthi]

@jormaechea Sorry for the late reply. Currently, I don't have time to implement that. Free feel to assign to other people that are interested. And the stream might be better to work with implementing the exteranlValue support as it is better to provide a customized stream instead of random binary. I'll create another issue to track the exteranlValue support

[Celthi]

@jormaechea It seems there is a workaround by specifying a header "content-type: application/octet-stream` in the response like

      responses:
        "200":
          description: The requested properties are successfully returned.
          content:
            application/octet-stream:
              schema:
                type: string
                format: binary
                example: 3456
          headers:
            content-type:
              schema:
                type:
                  string
              example: application/octet-stream

After providing the header in the response, the browser will treat the response as a file stream though the data is actually a string named "3456"

[jormaechea]

It's a great workaround. Definitely not the best solution, but it works for you.

I'll leave this issue open to implement a more elegant solution to handle response content-types