Re: safe PUT

On Fri, 29 Dec 1995, Dave Long wrote:

> 
> A mini-rant, from the application developer's perspective.
> 
> It's certainly worth considering low-level transport issues
> when working on these protocols, however:
> 
> * As an apps guy, I have _no control_ over the stack underneath
>   me.
>
> Unix boxes tend to implement TCP very well.  WINSOCKs come
> in all flavors, some better than others.  We've even used
> a package on the Mac that required a patch to select() to
> report reset connections.

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? 

> * Is HTTP tied to TCP?

Not in so many words, but IMHO yes. The spec talks of the connection as a 
"virtual circuit". In the Introduction:

  "It builds on the discipline of reference provided by the Uniform 
   Resource Identifier (URI), as a location (URL) or name (URN) [16], 
   for indicating the resource on which a method is to be applied."

and RFC 1738 (section 3.1) identifies the HTTP scheme as based on Internet 
protocols; hence the "//" after the "http:". There's always an IP 
address, and the port defaults to 80 -- *TCP* 80.

> I tend to think that many of the "problems" that HTTP-NG
> addresses are actually with TCP, not HTTP itself.   We've
> done work for firms that (horrors!) don't run a TCP network,
> but they still see that value of HTTP as a backbone IS protocol.
> 
> So, when I see references to "advertising different window sizes",
> or "doing a half-duplex shutdown()", I think that it's nice to know
> that we can optimize implementations for the commonly used (and
> correctly implemented!) transports, but it's much more important
> that the HTTP protocol solve problems *at its level of abstraction*,
> without making unusual demands upon the transport.

It really sounds as if you want HTTP to take extraordinary precautions 
against implementations. Dealing with TCP implementation failures 
is properly outside the scope of HTTP. As for a "non-TCP network", once 
you're past the issues of what an IP address could mean on such a 
network, you still have to figure out what HTTP could mean without a 
virtual circuit, i.e.

  (i) reliable delivery of stream data in sequence
  (ii) paired simplex channels to differentiate direction of data flow

TCP:-)

Or are you arguing that HTTP should assume a half-duplex transport
service (like, say, LU6.2)? 


Regards,

Arjun Ray

Received on Friday, 29 December 1995 21:26:04 UTC