End of Response

[hendrikebbers]

I haven't tested it until know but it looks to me that currently the end of a response in the stream is found by searching for 2 line feeds. I think this is wrong since the payload of a response can contain several line feeds in the data. As far as I know each request / response has a content length field that defines the size of the content / payload (in bytes / characters?). I think this must be checked to find the end of a request / reponse, right?

[Oliver-Loeffler]

Yes, that was my first attempt. Well, I'll fix this aspect tonight. As of now, only the first 1024 bytes are considered for reading the response. There is no valid mechanism yet to read the payload. So HttpResponse is not complete yet as it only covers the header fields.

[hendrikebbers]

I have a solution to read everything (continues reading). Currently at a customer and hope that I will have wifi in the train this evening. Otherwise I will try to do a PR tomorrow or monday.

…

Am 10.03.2017 um 10:12 schrieb Oliver Löffler ***@***.***>: Yes, that was my first attempt. Well, I'll fix this aspect tonight. As of now, only the first 1024 bytes are considered for reading the response. There is no valid mechanism yet to read the payload. So HttpResponse is not complete yet as it only covers the header fields. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJAaB100MYzH02ziOENiNRfvhEMfZxJ-ks5rkRPmgaJpZM4MZGlS>.

[Oliver-Loeffler]

So far reading stopped intentionally as I used this to explore how HTTP response headers look alike. I should be able to do something about this weekend.

[Oliver-Loeffler]

I found the particular section in the RFCs.

• http://httpwg.org/specs/rfc7231.html#payload
• http://httpwg.org/specs/rfc7230.html#message.body.length

In current implementation only the "header end" is determined correctly (CRLF+CRLF prior to payload body). The payload is currently simply what can be read from channel as long as it is open. In case of multiple consecutive messages this won't work. So here clearly some work has to be done.

I will consider all the boundary conditions and cases in section 3.3.3 message body length during writing of a request builder or producer.

Is there any kind of java based HTTP/1.1 HTTP/2 or HTTPS server which can be used as endpoint for integration testing and protocol exploration, something which can be integrated in a Maven flow? This would eliminate the need of having a separate server running or to confuse real-world servers with strange requests. Or is that over engineered?

Those HTTP Response and Request objects, shall they behave nicely conform to RFCs or just provide the data (responses) and handles for any kind of free form request building?