4 ms·
By "customhttp" I meant my hand-rolled (subset of)http-server. It doesn't support chunked encoding because I also control the client-code but it does support "c
by jackewiehose 7y ago
By "customhttp" I meant my hand-rolled (subset of)http-server. It
doesn't support chunked encoding because I also control the client-code
but it does support "connection keep-alive" for better performance.
I haven't testet it yet but I'm pretty sure its vulnerable: my server
just looks for content-length and if it doesn't find it, it returns an
error. So if nginx sends content-length but then continues to send
chunked content it should be possible that the next request won't come
from nginx but from an attacker (probably not really a problem at the
time but nevertheless not the expected behaviour).
My failure was to always expect "valid" HTTP-input from nginx whereas
"valid" means my limited knowledge of HTTP.
But the question remains: Is there a reason why nginx should send both
headers to the backend?
- tialaramex 7y agoIf you don't implement an encoding you should obey the HTTP/1.1 standard and "return 501 (Unimplemented), and close the connection". In your case even though not implementing chunked encoding is prohibited, this drop through would save you. Valid means what the standard says it means. What you don't know can hurt you. However, if modifying your backend code is hard, you can apparently tell nginx that you don't do chunked encoding and it will sort out the 501 on your behalf. I have not tried this and YMMV.
- jackewiehose 7y agoI completly agree and I'm sure nginx is doing it right by following the specification but isn't this a bug in the specification? Why should there be a content-length but then a chunked body. And if this is a bug in the specification, shouldn't nginx fix it to help us backend-fools?