Re: HTTP 1.1 As Universal Transport?

Anders Rundgren wrote:
> 
> Hi,
> I have read the 1.1 draft and I may have misundestood something
> but anyway I would like to get a personal reply.
> 
> In HTTP 1.1 you introduce persistant connections (as default?)
> Good!
> 
> But does this makes it possible for a server to send events to
> a client. I think not.
> Very sad.

Why not? 

> The reason that I want this is that today, Internet applications
> lack a universally supported protocol that can pass through firewalls.
> HTTP does that but HTTP 1.0 is almost useless for real interactivity
> as it lacks persistant connections and events from servers must be
> polled for.
> 
> Although it may sound like herrasy to just use HTTP as some kind of
> socket mechanism, this is really what you do when you use HTTP
> in Java.  And a new version should extend the use of HTTP so that
> all distributed objects etc. can ride on top of HTTP.

However, Java establishses a seperate and distinct protocol entity from HTTP 
and thus can be extended to encompass these additional mechanisms, think of 
HTTP (at least I do) as a connection ESTABLISHMENT and REQUEST mechanism, 
that facilitates additional (separate) protocol transactions at different 
user or client specified ports.
 
> SOCKS would be fine but it seems that firewall administrators
> just want ONE protocol to administer.  I understand them!
> 
> Regards
> Anders Rundgren
> Vincent Engineering

In conclusion;

I beg to differ:  If you make reference to server based applications which 
push data to the client several firewalls do support this operation, if you 
make reference to client directives that send timed requests to the server 
entity or proxy this is also supported.  I don't think a revision to the spec 
would be necessary to address this issue.

In addition, although HTTP would be a good candidate for a "_common_ client" 
transport mechanism the nature of the protocol would not allow several 
features, including unreliable transport mechanisms, which would require a 
completely NEW protocol enhancement or revision of the current specification.

Hotep,

Eric
Information Brokers, Inc.

Received on Thursday, 16 May 1996 09:37:38 UTC