[whatwg] General TCP connections API?

Hello,

On 5/26/05, Kornel Lesinski <kornel at ldreams.net> wrote:
> On Thu, 26 May 2005 23:10:00 +0100, Charles Iliya Krempeaux
> <supercanadian at gmail.com> wrote:
> 
> >> On your website, if you create iframe with URL:
> >> example.com/page.php?name=<script>connectPort(25).send("HELO...SPAM...SPAM");</script>
> >
> > I won't be a problem if the web developers is escaping whatever the
> > user supplies.
> 
> ...and HTML developers should write valid HTML, etc.
> 
> Sorry, but there is A LOT of totally ignorant/incompetent web developers
> and sysadmins.

Agreed.  But if you are going to not support (or allow) anything that
could screw up a system due to a mistake by an ignorant/incompetent
web developers or sysadmins then we might as well not allow the whole
concept of CGI, server side scripting, and dynamic database driven
websites.  (Since this could be used to screw up systems.)

Just look at how many people use an HTTP GET (instead of POST, PUT,
DELETE, or something else) to change things -- delete or update
records -- on the webserver.  This sometimes causes problems when
search engines crawl sites.  Does this mean we should get rid of
search engine web crawlers because some ignorant/incompetent web
developer doesn't understand the differences between the different
HTTP methods and how they should be used?

Sometimes ignorant/incompetent web developers pass input from CGI
variables to a system call (unescaped and unquoted).  This can be used
to do all sorts of malicious acts by allowing the user to run
arbitrary commands on the server.  Does this mean that we should get
rid of CGI and server side scripting?

I disagree that ignorance/incompetents web developers or sysadmins
should be a reason to not allow TCP connections.  Because, following
that line of reasoning would be an argument to get rid of CGI, server
side scripting, and database driven websites.

> > For example, let's say I want to stream images, or video, or audio,
> > from the client to the server.
> 
> and how are you going to decode and display them using Javascript?
> and how that is better than current streaming multimedia plugins? or Java?

The image streaming thing was just an example.  (I was trying to come
up with an example that could make use of a TCP connection.  Although
it is an example I was working on before.  The solution to this was to
write a native desktop application for Linux, Windows, and Mac. 
Although part of that was due to needing to access the camera and
microphone on the computer.)

Incidentally, Java provides a TCP connection API like the one I'm
proposing for web applications.  Refer to #8 in the Java Security FAQ:

    http://java.sun.com/sfaq/

I actually think Java would be an excellent solution.  (I actually
really liked it when the JVM was in virtually every browser.) 
However, today, it doesn't seem to be there on all browsers.  Last I
checked, it wasn't even included on Windows XP.  And isn't included on
most Linux distributions.  (Although correct me if I'm wrong.)  Today,
you have to download and install it yourself.

Which is why I think there should be a TCP connection API.  So that a
plain vanilla web browser (of tomorrow) can create a TCP connection
(without relying on extensions that may or may not be there).


> > And that there were some high "performance" demands
> > for this that HTTP couldn't meet.  (Like, for example, if I wanted to
> > push 24 frames per second from client to server.)
> 
> This doesn't make sense to me.
> 
> HTTP doesn't add any overhead to TCP/IP except headers (you don't have to
> use chunked encoding), so your custom protocol can't save you more than
> *one* IP packet per file! (and typically less thanks to keepalive
> connections)
> 
> For high performance you can't use TCP/IP and need some lower-level
> protocol like UDP and specially crafted data format that works with
> partial/out-of-order packets. That's absolutely not a thing anyone would
> dare to implement in Javascript.
> 

What I was talking about here was more about the cost of creating and
tearing down TCP connections when using the HTTP protocol, for each
request.  Although, it is true that the "persistentness" of HTTP/1.1
can help.  However, as I understand it, this "persistentness" can't be
depended on.  (The connection could be closed by the server.)  But
correct me if I'm wrong.  (Perhaps I just don't have enough knowledge
about tweaking a webserver for its persistentness.)


See ya

-- 
     Charles Iliya Krempeaux, B.Sc.

     charles @ reptile.ca
     supercanadian @ gmail.com
___________________________________________________________________________
  Wikibooks, Free Open-Content Books                  http://wikibooks.org/

Received on Thursday, 26 May 2005 22:58:08 UTC