From: Alexandre Ferrieux on
On Mar 10, 3:41 am, Bezoar <cwjo...(a)gmail.com> wrote:
>
> I had similar experience and had to change the code in that spot to
> talk to my web server (a Tivo). It was inserting some line feeds (\n)
> before the http status. I changed the code to make sure that I had non-
> whitespace before I set the state to header.  Even though the change
> was benign and would have made the package more robust,  when  I
> reported the bug, I was told that I should replace the web server.
> Even though I submitted the fix the maintainers refused to change the
> code. Bugs item #2874782https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2874782&...

Re-reading that bug's comments, I'd say the maintainers' position is
motivated by an estimation of the benefit/cost ratio that is different
from yours. Indeed, while the benefit for your server is obvious,
there is no hint at the significance of this server-side bug (do all
Tivo's do that ? Is there an old RFC or even de facto version of HTTP
that allowed that ?). On the cost side, while the fix you provided is
indeed trivial and does the job, it has the possible side-effect of
_masking_ a possible loss of sync between announced content-length and
actually sent data, in a previous HTTP request on the same TCP socket
(in keepalive connection mode). This argument was given in a comment
by Colin, but your reply missed the point about the keepalive mode.

Given this, I'd say your best bet is to come back with more evidence
that the bug is reproducible outside this single instance of buggy
server that you're hugging tight ;-)

-Alex