Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?



If 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.


I 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?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: