For 204 response the body should be empty... #321
Conversation
…tStream. When proxying through the server a body here will result in a `Transfer-Encoding:chunked` in the aleph server, basically stating the body size is unknown. Some caching products, like varnish, fails miserably here, e.g. gives the calling client back an http 503. With this change, at least when the body is empty it is removed, and the `Transfer-Encoding:chunked` is not added.
To avoid the reflection warning in the build.
|
I'd be interested in hearing @malcolmsparks thoughts on this, as Yada tries very hard to handle HTTP semantics well. I think Yada only sets a 204 on |
|
I am not too familiar with Yada, but if you are wrapping both aleph's client and server, and haven't done anything to prevent this, I think you will have the same issue. I guess this is a small issue, but it was very confusing when I ran into it. If others run into it in the future, there is at least a solution on the alephs mailing list (https://groups.google.com/forum/#!topic/aleph-lib/00pJj6s_UE0). |
|
This is only a problem when you're proxying through a However, this fix assumes the body is always an |
|
Ah right, I completely missed that this is a client 204, not a server 204 response, sorry. |
|
Go ahead, looking forward to seeing how to fix it properly. It was fun digging a bit in Aleph's code. |
...not an empty ByteArrayInputStream.
When proxying through the server a body here will result in a
Transfer-Encoding:chunkedin the aleph server, basically stating the body sizeis unknown. Some caching products, like varnish, fails miserably here, e.g. gives
the calling client back an http 503.
With this change, at least when the body is empty it is removed, and the
Transfer-Encoding:chunkedis not added.This seems to be working. I guess there is a deeper root cause here, somewhere in Netty perhaps? I would be happy to change this in any way you'd like, or attack the problem differently. Let me know.
Cheers,
Alf