[whatwg] General TCP connections API?

[Charles Iliya Krempeaux]

Hello,

On 5/26/05, Kornel Lesinski <kornel at ldreams.net> wrote:
> On Thu, 26 May 2005 21:30:18 +0100, Charles Iliya Krempeaux
> <supercanadian at gmail.com> wrote:
> 
> >> To have your own connections you'd have to use other port than 80 and
> >> that may be disallowed on many restricted systems.
> >
> > Could you please elaborate on this.
> 
> Clients that have many blocked ports on firewall - for example to block
> P2P inside school networks.

I made this argument in another e-mail too,... but I'll do it again....

I think that we should allow TCP connections, even if it won't work in
some cases.

For example, often people access the web on a computer at a cafe or
school that does not have an e-mail client.  In these cases the
"mailto" URL will not work.  However, we still allow the "mailto" URLs
in webpages.

Also, it could be the case that a network (on an office) bans outgoing
connects on any port other than 80 (for HTTP) and 443 (for HTTPS).
This would stop FTP URLs from working.  However, we still allow "ftp"
URLs in webpages.

In other words, "let me use it when I can use it".  (Since we are
already following this principle on the web.)

[...]

> >> Even if connections are limited to the same host, you couldn't safely
> >> serve anything else on it. Spammers might use numerous HTML-injection
> >> techniques to send spam using other people's computers, and this may get
> >> much worse if host restriction fails.
> 
> > Could you please elaborate on this.
> 
> Let's say there's website
> example.com/page.php?name=John
> that prints
> Hello "John"!
> 
> 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.  (This is developer error, ignorance, or stupidity.) 
For example, if the web developer is using PHP, then he should be
making use of the htmlspecialchars() function.  For example, their
code should be something like:

    <?php
    
        print('Hello "' . htmlspecialchars($_GET['name']) . '"!');
    
    ?>


Web developers should NOT be allowing arbitrary (HTML, JavaScript,
etc) code to get inserted into their webpages on their site!  (Even if
a web developer does this today, he allows the potential for havoc!)

I could also make an argument to NOT allow CGI parameters in the first
place because people could potentially use it to make system calls. 
For example, consider that I have a script that gives me "finger" info
for users of the system.  And suppose it is usually called with
something like:

    http://example.com/finger.cgi?username=joeblow

And that this is implemented with a system call.  Maybe something like:

    <?php
    
        system('finger ' . $_GET['username']);
    
    ?>

Then there would be a problem if I called this URL with something like:

    http://example.com/finger.cgi?username=joeblow;rm+-fR+.

Then the command wouldn't just be:

    finger joeblow

But would be

    finger joeblow; rm -fR .

(Which could delete a hole bunch of stuff.)

I don't think developer error, ignorance, or stupidity should be an
argument to not allow TCP connections.

> every visitor will send spam using example.com server.
> 
> 
> On a second thought this may be prevented by forcing some special
> handshake or transport protocol for custom connections...
> but then this feature becomes just alternative HTTP + XML RPC that only
> offers smaller lag for price of increased complexity and worse
> browser/server support. Is it worth it?

The argument for allowing TCP connections isn't so that a small drop
in lag can be obtained.  But so that things that otherwise could not
be solved using HTTP can be solved (using a custom protocol).  (Please
refer to my "streaming images at 24 frames per second" example in the
other e-mail I wrote.)


See ya

> --
> regards, Kornel Lesinski
> 


-- 
     Charles Iliya Krempeaux, B.Sc.

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