[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100927192112.GT12373@1wt.eu>
Date: Mon, 27 Sep 2010 21:21:12 +0200
From: Willy Tarreau <w@....eu>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org
Subject: Re: TCP: orphans broken by RFC 2525 #2.17
On Mon, Sep 27, 2010 at 12:42:39AM -0700, David Miller wrote:
> I still think it's completely broken that you want to close a
> connection for which data is still going to arrive.
>
> And I really can't think of why this can't be solved at the
> application level.
>
> Either there is an application level ACK that you have to wait for
> anyways, or there isn't and you receive the entire request packet
> before you start sending the data.
>
> If there is some kind of unpredictable "dribbling" after the request
> arrives, you really have to fix that.
>
> I honestly have no sympathy for an application level protocol that
> works this way, and I don't think the kernel is the place where this
> should be handled.
>
> Please don't exhaust me any further on this issue, thank you.
David,
I don't want to exhaust you on the issue and I really understand that
you quickly read my explanations and don't get the issues.
Two quick facts :
- HTTP allows the client to send whatever it wants whenever it wants
and allows the server to close after whatever response it wants.
Thus the server cannot predict that the client will talk.
- orphans don't work anymore, period. Why not remove that whole code
if you pretend it must not be used ? You still did not reply to this
point, and I'm sure you will still not respond to this, probably
because you've realized that there is indeed a bug which is probably
not easy to solve, given the limited use it has.
Please, wait for a moment when you have a bit more spare time and check
what the orphans may be used for with this issue => nothing. That's why
I'm trying to discuss a possible fix.
Thanks,
Willy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists