Hi @Jochen Deubner,

Great question!  I ran into the same behavior 🙂

You're right that the CSP Gateway tends to buffer responses, which prevents intermediate flushes from reaching the browser, even when using SSE-friendly headers like text/event-stream

That said, it is still possible to stream the response.

In addition to setting the Content-Type to text/event-stream, you also need to explicitly allow output flushing in your REST service:

Set %response.AllowOutputFlush = 1

Then, whenever you want to push data to the client, you can call:

Do %response.Flush()

Example with fast-http

You can implement a simple passthrough adapter like this:

Class dc.http.SSEPassthroughAdapter Extends dc.http.SSEAdapter
{

Method OnMessage(item As dc.http.SSEMessage) As %Status
{
    Write item.Raw
    If $IsObject($Get(%response)) {
        Do %response.Flush()
    }
    Return $$$OK
}

}

I think this kind of passthrough adapter could be useful for other developers as well, so I’ll probably add it directly into fast-http.

And use it like this:

Set %response.AllowOutputFlush = 1
Set %response.ContentType = "text/event-stream"

Set stream = ##class(dc.http.SSEPassthroughAdapter ).GetStream()
Set handler = .SSEHandler
Set handler.SwitchIOOnMessage = 1
Set handler.IO = $IO

Set body = {"model": "gpt-4","messages": [{"role": "user", "content": "Tell me a short story."}],"stream": true}
Set response = ##class(dc.http.FastHTTP).DirectPost("url=https://api.openai.com/v1/chat/completions,Header_Authorization=Bearer {MyToken}", body, .client, stream)

Note: The REST class parameter Parameter IgnoreWrites = 0; should be set to 0.

If you're interested, I can provide a complete working example on my GitHub (on a demo branch).

Hope this helps.

Edit

I added the branch csp-test-1  to illustrates how to set up a passthrough for the OpenAI API with streaming support over CSP.

Clone the repository, switch to the specific branch csp-test-1, and start the environment using Docker:

git clone -b csp-test-1 https://github.com/lscalese/iris-fast-http.git
cd iris-fast-http
docker compose build --no-cache
docker compose up -d

To use the OpenAI API, you must configure your API key in the IRIS instance. Open a terminal and run:

Set ^APIKey = "sk-..." ; your OpenAI API key

Access the built-in chat interface at: http://localhost:42600/csp/ui/demo/chat.html

The backend logic is implemented in dc.http.DemoRest. You can adapt this class to match your specific testing requirements.

Thanks a lot for your kind words, that’s very encouraging!

Thank you @Guillaume Rongier !

I'll publish a French version soon.

Yes, that's it!
The methods generated in the “impl” class must return a %DynamicObject.  I think %WriteResponse accepts string, stream or %DynamicObject as parameters, but the most common usage is still %DynamicObject (The developer will always be free to modify according to his implementation) .  I'll put an issue on github for follow-up and fix it.  
edit: done in version 1.1.1

Great!
Probably an oversight in the return type when generating the code.  
I'll take a look.

Hi @Evgeny Shvarov !

I've just seen your message, I'll try to rebuild this project tomorrow, as I haven't had the opportunity to use it for a while.  I'm sure I've got a simple specification to test somewhere.

If you want, you can send me your specification by private message (discord) and I'll test it :)

Finally, there is a solution @Theo Stolker .
If I parse by URL and send parameters "resolveFully=true" and "validateExternalRefs=true", the specification is fully resolved including external references.  I can't commit\push this update directly, because if a user puts a URL only accessible from inside his organization, It does not work.  It's not really a problem because the validator tools can be run locally in a container, but I have to update the documentation too.
I created the related issue 9 to follow the progression.  I can't continue anymore this morning.  I'll continue this evening.

Thank you very much for your contribution @Theo Stolker .
Your pull request is merged and a new release on OEX has been published.  

I'm still wondering if there is a simple way to resolve external references, I'll check if something help with validator.swagger.io (this tools is already used by OpenAPI suite).  There is an option for external ref but I don't know yet what that implies, I have to test that.

Hi @Theo Stolker ,

I just tested the "DID Manager" specification.

With the simple http client, I noticed a code generation issue with double-quoted HTTP status code. It's fixed.

I see a generated model like model.CompoundServicePropertiesserviceEndpoint empty. So, If we check the specification and we can see:

        serviceEndpoint:
          description: A map containing service references and/or endpoints.
          example: { 'auth': 'did:nuts:EwVMYK2ugaMvRHUbGFBhuyF423JuNQbtpes35eHhkQic/serviceEndpoint?type=auth' }
          type: object

It's a type object, but there is no schema defined, so we can't generate any properties in this case.
This is the same problem with the model model.OrganizationSearchResultorganization.

I also noticed external references in the specification file like :

        didDocument:
          $ref: '../common/ssi_types.yaml#/components/schemas/DIDDocument'

Indeed, this case is not supported. I haven't checked for all the specs, but I think the 2 cases noted are the cause for the empty models.

If we specify a URL, maybe it would be possible to download the external ref and load the definition (to analyze...).

Hi @Theo Stolker 

Thank you for your report!  I'll try these specifications.
Yes, we can discuss on Discord or using 'issue' on the GitHub page.

What operation did you do? (generate simple HTTP client or client production?)

Ho interesting! I never noticed the flag argument of the function $ListToString.