>Sorry, why are broken stacks _your_ problem? Given an API to program to,
>how do you really expect to cater to broken implementations of the API?
I'm sorry, I wasn't clear. I meant that if HTTP is simple enough,
then I don't have to cater to broken implementations of the API.
(assuming that the "broken" implementations are mostly functional,
only broken when one tries to use them in more esoteric ways)
So it would be nice to stick with something that can be implemented
given *only*:
> (i) reliable delivery of stream data in sequence
> (ii) paired simplex channels to differentiate direction of data flow
and not worry about half-duplex shutdown, OOB packets, MSS, etc.,
except as potential optimizations.
It sounds like we're in violent agreement, but I didn't express
myself well.
-Dave
>Or are you arguing that HTTP should assume a half-duplex transport
>service (like, say, LU6.2)?
Not necessarily, given that I'm advocating a full-duplex PUT :-)
However, my PUT definition still works over a half-duplex channel,
it just degrades to the HTTP/1.0 PUT worst-case.