On Mon, Sep 27, 2010 at 12:42:39AM -0700, David Miller wrote:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html