Re: Rechartering HTTPbis

On Fri, Jan 27, 2012 at 03:28:31AM +1300, Adrien de Croy wrote:
> 
> 
> On 27/01/2012 3:11 a.m., Willy Tarreau wrote:
> >On Thu, Jan 26, 2012 at 02:05:56PM +0000, Poul-Henning Kamp wrote:
> >>In message<20120126140301.GG8887@1wt.eu>, Willy Tarreau writes:
> >>
> >>>OK, but in the context I said that, we were talking about chunking.
> >>>And this is still true. A chunked-encoded transfer that does not end
> >>>with the last 0-byte chunk *is* always an indication of a truncate.
> >>Yes, absolutely.  I just wish there were a way to end the transmission
> >>and say: "Sorry, that went awry, but we can still use this connection.
> >The only solution I can think of would be to send padding up to the
> >current chunk size
> 
> only if you're mid-chunk when you decide that the chunk you started 
> sending you don't want to any more.
> 
> Maybe you shouldn't have decided to send it if you weren't ready.

That's not what I'm saying. Again, any intermediary has many reasons
to close anywhere. Many do not even know what HTTP is nor what a
chunk is. Chunks are not atomic. And even intermediaries which talk
HTTP cannot all buffer all chunks. When you have a 16kB buffer per
connection, a chunk rarely fits there so you have to transfer as you
get them.

> >and advertise "0" with some extension to indicate
> >the wish to reuse the connection. But I really think that the cost of
> >handling all impacts of a failed connections sensibly offsets the small
> >expected gain for these rare conditions.
> 
> Sure the number of reset connections is very small, and you can't 
> advertise anything anyway since you can't send any more.
> 
> This is only useful when you want to abort, and you can do so on any 
> chunk boundary.  Those that wish to use this can tweak their code to 
> make it effective, those that don't or just want to pass stuff through, 
> that's fine.
> 
> But checking for attributes on the final 0 chunk seems to me to be a 
> cheap way to get the benefit of abort when you want it.
> 
> I'd suggest the number of aborted sends due to content would outweigh 
> network errors.

It depends on the environment. In your products since you have valid
reasons to abort when matching contents, that's certainly true. But I
know many other infrastructures where no such filtering happens, and
the primary reason for an abort is a timeout, the second one is the
usual process crash in the middle of a processing due to an application
bug.

> But anyway, it's a basic principle, if you make a decision that affects 
> another party, you should communicate it.  If you can't you can't, but 
> you shouldn't say "Because I can't ALWAYS communicate it, I will choose 
> instead to NEVER do it".  That's sociopathic :)

I agree with this point of view. As I said, what I'm against is making
it harder to support the normal case just to favor better error recovery
for the fatal cases. For instance, re-opening a connection is cheap. OK
it's a round-trip, but if it happens less that 1/10000 times it's probably
better than padding megabytes of chunks or making parsers more complex.

Willy

Received on Thursday, 26 January 2012 16:10:16 UTC