Incorrect reply for status 204 in http2

[Hemant Zope]

When the h2o server is replying with 204 No Content Status code, h2o is sending data frame for End Stream flag. It shows data missing.

The correct way should be, in header frame, End Stream flag should be set along with End Headers

HyperText Transfer Protocol 2
    Stream: HEADERS, Stream ID: 1, Length 21, 204 No Content
        Length: 21
        Type: HEADERS (1)
        Flags: 0x04, End Headers
            00.0 ..0. = Unused: 0x00
            ..0. .... = Priority: False
            .... 0... = Padded: False
            .... .1.. = End Headers: True
            .... ...0 = End Stream: False
        0... .... .... .... .... .... .... .... = Reserved: 0x0
        .000 0000 0000 0000 0000 0000 0000 0001 = Stream Identifier: 1
        [Pad Length: 0]
        Header Block Fragment: 8976929c47604bb2b816bf838ffe84c91f6db9464f
        [Header Length: 55]
        [Header Count: 2]
        Header: :status: 204 No Content
        Header: server: h2o/2.3.0-DEV@23c955fac
    Stream: DATA, Stream ID: 1, Length 0
        Length: 0
        Type: DATA (0)
        Flags: 0x01, End Stream
        0... .... .... .... .... .... .... .... = Reserved: 0x0
        .000 0000 0000 0000 0000 0000 0000 0001 = Stream Identifier: 1
        [Pad Length: 0]
        Data: <MISSING>

[Kazuho Oku]

Thank you for reporting the issue.

What is the client that has issues with handling the response?
Could you pinpoint us to where such behavior is prohibited?

I think that for a very long time we have been terminating 304 (a popular status code) using an empty DATA frame with END_STREAM flag, but have not have received complaints.

[Hemant Zope]

Thank you for your response.

I am using libcurl, I dont think libcurl has any issue with this response.

I think this behaviour is not prohibited, but as the header field already supports the END_STREAM flag, I believe sending an extra data frame is not needed as there is no data to be sent.

[Kazuho Oku]

Thanks. Closing as this is a permitted behavior.

And FWIW, the reason I do not want to change current behavior is because such proxies already exist. When h2o running as a proxy receives a 204 response from an upstream server using HTTP/2, that closes the stream using a zero-length DATA frame with the END_STREAM flag, it is much simpler to just forward that to the client.

Converting that to a response that closes the stream with HEADERS + END_STREAM is going to be complex.