Stop the IdHTTP.Post stream upload without closing the connection

[rlebeau]

Is there some way to interrupt the uploading of the stream, as if the data has ended, but without raising exceptions and closing the connections?

No, there is not.

I am migrating some Java code that deals with a tus server. And one of the methods seems to do exactly the above. It make a patch request, uploads a stream, but it also has the option to stop the upload. When it is stopped, the client stops uploading the stream, but afterwards still reads the response from the server over the same connection. That response contains information about the data uploaded.

In standard HTTP, an HTTP server cannot send a response until the request is finished (unless an error occurs, then a response can be sent sooner). The only way an HTTP client can stop a request prematurely without breaking the connection is if the client is sending an HTTP 1.1 request that contains body data encoded in the 'chunked' transfer encoding, and simply stops sending chunks, sending a 0-length chunk to end the body. HTTP 1.1 allows this for requests, but TIdHTTP does not currently support sending chunked requests, only reading chunked responses.

However, tus is not using standard HTTP as-is. It defines its own protocol on top of HTTP to handle partial and resumable uploads beyond what HTTP provides (by utilizing a custom application/offset+octet-stream media format for the Content-Type header, and custom Upload-Offset and Upload-Length headers). It does not utilize HTTP's 'chunked' feature.

The actual tus protocol is defined on the tus website:

resumable upload protocol

Based on what I see in that protocol spec, the only provision I see for stopping an upload in progress is the following:

The tus protocol is built upon the principles of simple pausing and resuming. In order to pause an upload you are allowed to end the current open request. The Server will store the uploaded data as long as no violations against other constraints (e.g. checksums) or internal errors occur.

But, it does not say HOW to "end the current open request" exactly. The only way HTTP allows ending a request prematurely is to close the connection, unless 'chunked' is being used for the body data.

Otherwise, the tus protocol does allow an upload to be broken up into smaller pieces, each one sent with its own PATCH request:

The Client SHOULD send all the remaining bytes of an upload in a single PATCH request, but MAY also use multiple small requests successively for scenarios where this is desirable. One example for these situations is when the Checksum extension is used.

So, maybe your Java client is simply doing that, and ends the "current" PATCH request normally when requested to stop uploading.

Another possibility is for a tus client to simply stop sending without actually ending the request, letting the server timeout on its end.

Both, Client and Server, SHOULD attempt to detect and handle network errors predictably. They MAY do so by checking for read/write socket errors, as well as setting read/write timeouts. A timeout SHOULD be handled by closing the underlying connection.

A tus server is required to store whatever data it receives, even if errors occur. If the client intentially causes a timeout, the connection is still open, and maybe the server sends a (failed) response before closing the connection on its end.

Who knows what your Java client is actually doing. You will just have to study its source code, or sniff its HTTP traffic, and see for yourself.

Looking at the code I could not find a clever solution. The uploading of the stream is called by TIdCustomHTTP.ConnectToHost and handled inside TIdIOHandler.Write and WriteDirect. But I didn't see how it can be interrupted midway without raising an exception, which then closes the connection.

Correct. There is currently no supported option to interrupt an upload in progress without breaking the connection. If TIdHTTP does not suit your needs, you can always use TIdTCPClient instead, and then you have full control to implement the HTTP and tus protocols however you want.