(Sorry if this counts as thread necromancy. The discussion just didn't
seem to have come to an end yet.)
On Fri, Jun 20, 2008 at 3:55 PM, Frode Børli [EMAIL PROTECTED] wrote:
I would manage, but i do not like the implementation (it is much more
complex than it needs to be). I would basically
It is worth spending months improving the implementation here, if it
saves only one minute of work for each of the millions of web
developers out there, in the future.
Alright, point taken. You're of course absolutely right with that :)
I agree, it would be very convenient to basically set
Rewriting the HTTP spec is not feasible and I'm not even convinced its a
good idea. HTTP has always been request/response so it would make a lot
more
sense to simply use a new protocol then confuse millions of
developers/administrators who thought they understood HTTP.
As pointed out by
I fail to see how virtual hosting will work for this anyway. I mean we're
not talking about Apache/IIS here, we're talking about custom applications,
scripts or devices - possibly implemented in firmware or a few lines of
perl. Adding vhost control to the protocol is just silly since the
able to use any method it likes to differentiate its services. Even URI
addressing is silly since again the application may have no concept of
paths or queries. It is simply a service running on a port. The only
valid use case for all this added complexity is proxying but nobody has
tested
I think we should have both a pure TCPSocket, and also a ServerSocket
that keeps the same connection as the original document was downloaded
from. The ServerSocket will make it very easy for web developers to
work with, since the ServerSocket object will be available both from
the server side
I think we should have both a pure TCPSocket, and also a ServerSocket
that keeps the same connection as the original document was downloaded
from. The ServerSocket will make it very easy for web developers to
work with, since the ServerSocket object will be available both from
the server side
without informing the user. This would allow a popular page (say a facebook
profile or banner ad) to perform massive DOS against web servers using
visitors browsers without any noticeable feedback (though I guess this is
also true of current HTTPXMLRequestObjects).
XMLHttpRequest only allows
Frode Børli wrote:
XMLHttpRequest only allows connections to the origin server ip of the
script that created the object. If a TCPConnection is supposed to be
able to connect to other services, then some sort of mechanism must be
implemented so that the targeted web server must perform some sort
The protocol should not require any data (not even hello - it should
function as an ordinary TCPConnection similar to implementations in
java, c# or any other major programming language. If not, it should be
called something else - as it is not a TCP connection.
I agree completely. Just
On Wed, 18 Jun 2008, Michael Carter wrote:
In that case I agree that the name shouldn't be TCPConnection. I propose
SocketConnection instead.
I was thinking WebSocket (with the protocol itself called the Web Socket
Protocol or Web Socket Communication Protocol or some such).
--
Ian
On Wed, Jun 18, 2008 at 12:59 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 18 Jun 2008, Michael Carter wrote:
In that case I agree that the name shouldn't be TCPConnection. I propose
SocketConnection instead.
I was thinking WebSocket (with the protocol itself called the Web Socket
Still I do not believe it should have a specific protocol. If a
protocol is decided on, and it is allowed to connect to any IP-address
- then DDOS attacks can still be performed: If one million web
browsers connect to any port on a single server, it does not matter
which protocol the client
I think a major problem with raw TCP connections is that they would be
the nightmare of every administrator. If web pages could use every
sort of homebrew protocol on all possible ports, how could you still
sensibly configure a firewall without the danger of accidentally
disabling mary sue
ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
I understand the reasoning but I do not believe this should be limited
to ports 80 and 443. By doing so we render the protocol difficult to use
as many (if not most) custom services would need to run on another port
to avoid
On Wed, 18 Jun 2008, Shannon wrote:
ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
I understand the reasoning but I do not believe this should be limited
to ports 80 and 443.
You misunderstand; it's not the ports that are limited, it's just that the
traffic can now pass for
16 matches
Mail list logo
