In http2, you can send a header response back 'before' the body of the request is fully sent. Of course, you then have to deal with sending an http 200 OK response and then something failing later. This is fine for us. I am wondering for a streaming upload case of ndjson, if we can do the same. Send back a response before the stream is fully sent.
ie. 1. http1.1 request received 2. We do authentication and if success, we send back http 200 OK while they are streaming a request body in 3. As we process the stream of ndjson, each record, we stream back a success or failure so they can easily pick up where they left off
This solution then allows them to send in 1 record or as many records as they want. I know the webserver we have supports this but not sure about all the clients out there. I am curious if there is anything in the spec that says this is a violation of the spec though?
thanks, Dean
Sending the response headers before reading the request content is possible in HTTP/1.1 too.
In fact, historically this has always been possible in HTTP/1.1 and HTTP/2 has just inherited this behavior from its predecessor.
A typical case is when the server application produces an unexpected error (for example, in Java, a NullPointerException): the server application cannot read the request content that the client is still sending (because of the unexpected error), and the server typically produces a response 500 indicating that it wants to close the connection.
Another typical case is a echo or transforming server, where you upload some content that gets echoed or transformed on-the-fly and sent back to the client.
Proxies are a primary example of the fact that HTTP is full duplex - a proxy does not buffer the request content before sending it to the server, and if the server replies while the proxy is sending the request, the proxy does not buffer the response content either (waiting for the request to complete) - it just sends the response content to the client.
While this full duplex behavior is not explicitly stated in the specification, it obviously happens in real life, so both clients and servers should handle this situation properly.
If I understand correctly, you use a JSON protocol on top of HTTP to notify the client of every JSON chunk that has been processed by the server. You basically have a "long" request with a "long" response and this should work perfectly fine in any decent HTTP implementation.