17.10.2009, в 3:20, Ian Hickson написал(а):
I'm not really sure what else to say to be honest. Should I just
leave it
at cookies and nothing else? Really I just want to support Basic
(and I
guess Digest) authentication (primarily for over-TLS connections),
so that
sites that use Basic
(cc'ing hybi by request, since changes to the WebSocket spec are
discussed below)
On Thu, 22 Oct 2009, Alexey Proskuryakov wrote:
17.10.2009, в 3:20, Ian Hickson написал(а):
I'm not really sure what else to say to be honest. Should I just leave
it at cookies and nothing else? Really I
On Wed, 14 Oct 2009, Alexey Proskuryakov wrote:
13.10.2009, в 4:11, Ian Hickson написал(а):
Is this meant to mimic some behavior that existing clients have for
HTTP already?
Yes, as it says, the idea is for UAs to send the same headers they
would send if the protocol had been
13.10.2009, в 4:11, Ian Hickson написал(а):
Is this meant to mimic some behavior that existing clients have for
HTTP
already?
Yes, as it says, the idea is for UAs to send the same headers they
would
send if the protocol had been HTTP.
For HTTP, this depends on authentication scheme in
On Mon, 31 Aug 2009, Alexey Proskuryakov wrote:
9. If the client has any authentication information ... that would
be relevant to a resource accessed over HTTP, if /secure/ is false, or
HTTPS, if it is true, on host /host/, port /port/, with /resource
name/ as the path (and possibly
On Thu, 13 Aug 2009, Alexey Proskuryakov wrote:
13.08.2009, в 4:42, Ian Hickson написал(а):
A note explaining that the close event will be dispatched at
server's discretion (or on subsequent connection timeout),
potentially long time after close() is called, would likely make the
04.08.2009, в 16:47, Ian Hickson написал(а):
I've added support for redirects. While I was at it I also added
support
for authentication.
Reading the authentication part of the latest draft, I had several
comments:
9. If the client has any authentication information ... that would
13.08.2009, в 4:42, Ian Hickson написал(а):
A note explaining that the close event will be dispatched at server's
discretion (or on subsequent connection timeout), potentially long
time
after close() is called, would likely make the intention clearer.
It won't be long after the close().
On Tue, 28 Jul 2009, Alexey Proskuryakov wrote:
28.07.2009, в 16:40, Ian Hickson написал(а):
3) A Web Sockets server cannot respond with a redirect to another
URL. I'm not sure if the intention is to leave this to
implementations, or to add in Web Sockets v2, but it definitely
04.08.2009, в 16:47, Ian Hickson написал(а):
The text Closing the connection causes a close event to be fired
and the
readyState attribute's value to change, as described below is not
normative (it has no musts in it). It's just letting you know that
subsequent requirements as described
On Wed, 29 Jul 2009, Fumitoshi Ukai (��~\飼�~V~G�~U~O) wrote:
I'm wondering why send() doesn't raise INVALID_STATE_ERR exception when
readyState is CLOSED and is required to queue up the data after closed.
What is the reason for this behavior?
So that scripts don't get unexpected exceptions
On Wed, Jul 29, 2009 at 1:33 AM, Ian Hickson i...@hixie.ch wrote:
Yes. But that's the case anyway -- events are asynchronous, so consider
the case of receiving two messages. Both are queued up, then eventually
the first is dispatched. If in response to that you close the connection,
that
On Tue, 14 Jul 2009, Jeremy Orlow wrote:
I think 'readyState' should just go away since an application will
have to keep track of state updates through the fired events and use
try/catch blocks around all API calls anyway.
The attribute is mostly present for debugging purposes. I
On Tue, Jul 28, 2009 at 4:40 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 14 Jul 2009, Jeremy Orlow wrote:
If it's only for debugging purposes, maybe a cleaner way to define it is
to simply be the last event fired on a given WebSocket?
I don't really understand what problem we would be
On Tue, Jul 28, 2009 at 4:40 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 14 Jul 2009, Jeremy Orlow wrote:
I think 'readyState' should just go away since an application will
have to keep track of state updates through the fired events and use
try/catch blocks around all API calls
28.07.2009, в 16:40, Ian Hickson написал(а):
3) A Web Sockets server cannot respond with a redirect to another
URL.
I'm not sure if the intention is to leave this to implementations,
or to
add in Web Sockets v2, but it definitely looks like an important
feature
to me, maybe something
On Tue, Jul 28, 2009 at 8:57 PM, Alexey Proskuryakov a...@webkit.org wrote:
28.07.2009, в 16:40, Ian Hickson написал(а):
3) A Web Sockets server cannot respond with a redirect to another URL.
I'm not sure if the intention is to leave this to implementations, or to
add in Web Sockets v2,
06.07.2009, в 21:30, Ian Hickson написал(а):
postMessage() may want another exception condition... 'too much data
pending exception'... consider calling postMessage in a while(true)
loop... at some point the system is going to have to give up queing
the
data if its not actually making its
27.07.2009, в 12:35, Maciej Stachowiak написал(а):
However, I do not think that raising an exception is an appropriate
answer. Often, the TCP implementation takes a part of data given to
it, and asks to resubmit the rest later. So, just returning an
integer result from send() would be
On Mon, Jul 27, 2009 at 1:14 PM, Alexey Proskuryakov a...@webkit.org wrote:
27.07.2009, в 12:35, Maciej Stachowiak написал(а):
However, I do not think that raising an exception is an appropriate
answer. Often, the TCP implementation takes a part of data given to it, and
asks to resubmit
On Mon, Jul 27, 2009 at 1:14 PM, Alexey Proskuryakov a...@webkit.org wrote:
27.07.2009, в 12:35, Maciej Stachowiak написал(а):
However, I do not think that raising an exception is an appropriate
answer. Often, the TCP implementation takes a part of data given to it, and
asks to resubmit
27.07.2009, в 13:20, Jeremy Orlow написал(а):
I agree that this will help if the application sends data in burst
mode, but what if it just constantly sends more than the network can
transmit? It will never learn that it's misbehaving, and will just
take more and more memory.
An example
On Mon, Jul 27, 2009 at 1:36 PM, Alexey Proskuryakov a...@webkit.org wrote:
27.07.2009, в 13:20, Jeremy Orlow написал(а):
I agree that this will help if the application sends data in burst mode,
but what if it just constantly sends more than the network can transmit? It
will never learn
On Mon, Jul 27, 2009 at 1:44 PM, Drew Wilson atwil...@google.com wrote:
On Mon, Jul 27, 2009 at 1:36 PM, Alexey Proskuryakov a...@webkit.orgwrote:
27.07.2009, в 13:20, Jeremy Orlow написал(а):
I agree that this will help if the application sends data in burst mode,
but what if it just
On Mon, Jul 27, 2009 at 2:02 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Jul 27, 2009 at 1:44 PM, Drew Wilson atwil...@google.com wrote:
On Mon, Jul 27, 2009 at 1:36 PM, Alexey Proskuryakov a...@webkit.orgwrote:
27.07.2009, в 13:20, Jeremy Orlow написал(а):
I agree that this
On Jul 27, 2009, at 2:14 PM, Alexey Proskuryakov wrote:
27.07.2009, в 12:35, Maciej Stachowiak написал(а):
However, I do not think that raising an exception is an
appropriate answer. Often, the TCP implementation takes a part of
data given to it, and asks to resubmit the rest later. So,
On Jul 27, 2009, at 2:44 PM, Drew Wilson wrote:
There's another option besides blocking, raising an exception, and
dropping data: unlimited buffering in user space. So I'm saying we
should not put any limits on the amount of user-space buffering
we're willing to do, any more than we
Why not just allow unlimited buffering, but also provide an API to query how
much data is currently buffered (approximate only, so it would be OK to just
return the size of data buffered in user space)?
Then applications that care and can adapt can do so. But most applications
will not need to.
Obviously we need more web platform capabilities to make such use cases a
reality, but they are foreseeable and we should deal with them in some
reasonable way.
Couldn't agree more.
The proposed websocket interface is too dumbed down. The caller doesn't know
what the impl is doing, and the impl
On Mon, Jul 6, 2009 at 9:30 PM, Ian Hickson i...@hixie.ch wrote:
1) The 'readyState' attribute can never actually be used by an
application
and is redundant.
Initially, the 'readyState' attribute is set to CONNECTING, but while
the object is in this state the user is not permitted to
On Mon, Jul 6, 2009 at 9:30 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 26 Jun 2009, James Robinson wrote:
0) postMessage() looks as if it is intended to mimic
MessagePort.postMessage(), but the arguments and error conditions are
different. While it would be conceptually nice to treat
On Tue, 7 Jul 2009, Michael Nordman wrote:
I think when we add support for file upload, we'll make it so that it
automagically supports this case. That is, you'll say upload this
file in small bits and then if you later say send this text
message, the text message will be sent before
On Fri, 26 Jun 2009, James Robinson wrote:
0) postMessage() looks as if it is intended to mimic
MessagePort.postMessage(), but the arguments and error conditions are
different. While it would be conceptually nice to treat a web socket in
the same way as a message port, it's not possible
On Sat, Jun 27, 2009 at 3:18 PM, Jeff Walden
jwalden+wha...@mit.edujwalden%2bwha...@mit.edu
wrote:
On 26.6.09 16:49, Michael Nordman wrote:
Progress bars are routinely implemented without get hi-level application
acks from the other side. XMLHttpRequest.upload.onprogress is one such
Cellular phone signal strength bars are not implemented on top of Web
Sockets so this cannot make a use case. This is rather a hardware thing.
On the other hand, I concur that a network queue overflow should be handled
differently than an out-of-memory condition. For example, if you have an
Given the evident complexity of the Web Sockets protocol with respect to
acknowledgements, events and updating host state for the script, is there a
modelling diagram to view?
Chris
On 26.6.09 16:49, Michael Nordman wrote:
Progress bars are routinely implemented without get hi-level application
acks from the other side. XMLHttpRequest.upload.onprogress is one such
example.
That they can be implemented this way does not imply they must be implemented
this way. I don't
Hello,
I'm very excited about the concept of web sockets and look forward to
building apps with it but the web sockets API at
http://dev.w3.org/html5/websockets/ has some issues. Many issues seem to be
inherited from the original XmlHttpRequest specification, which was
extremely useful but not a
On Fri, Jun 26, 2009 at 9:18 AM, James Robinson jam...@google.com wrote:
However, users can't usefully check the readyState to see if the WebSocket
is still open because there are not and cannot be any
synchronization guarantees about when the WebSocket may close.
Is this true? Based on our
On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 9:18 AM, James Robinson jam...@google.com wrote:
However, users can't usefully check the readyState to see if the WebSocket
is still open because there are not and cannot be any
synchronization
Yes, but the closed state of a given WebSocket doesn't have to exactly
match the state of the underlying TCP connection, in the same way that
document.cookies doesn't exactly match the current set of cookies that the
network stack may be tracking (they can differ when HTTP responses are
received
One thing about postMessage that I'm curious about. Since it has to report
failure synchronously by throwing an INVALID_STATE_ERR, that seems to imply
that all data must be written to a socket before returning and cannot be
asynchronously delivered to an I/O thread without adding some risk of
Oh and one more thing:
Doesn't it seem strange that disconnect() causes an onclose event to be
dispatched? Should the method not be close() to be consistent with open(),
onopen, onclose?
/kel
On Fri, Jun 26, 2009 at 4:14 PM, Kelly Norton knor...@google.com wrote:
One thing about postMessage
Does disconnect() attempt to flush pending messages or drop them?
There isn't a way to determine if the WebSocket is successfully sending the
postMessage data? For all the caller knows, its just backing up and not
going anywhere.
Something that might add value is an onmessagesent event that fires
On Fri, Jun 26, 2009 at 1:14 PM, Kelly Norton knor...@google.com wrote:
One thing about postMessage that I'm curious about. Since it has to report
failure synchronously by throwing an INVALID_STATE_ERR, that seems to imply
that all data must be written to a socket before returning and cannot
Not changing variables out from under executing JavaScript makes a lot of
sense, but if that was the case then it's not clear when the readyState
could be updated. The spec states When the *Web Socket connection is
closed*, the
On Fri, Jun 26, 2009 at 5:01 PM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 1:14 PM, Kelly Norton knor...@google.com wrote:
One thing about postMessage that I'm curious about. Since it has to report
failure synchronously by throwing an INVALID_STATE_ERR, that seems to
On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.com wrote:
Forcing applications to build their own send/ack functionality would be
pretty tragic considering that WebSockets are built on top of TCP.
- James
Every time I've written a response/reply protocol on TCP I've needed
On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.com wrote:
Forcing applications to build their own send/ack functionality would be
pretty tragic considering that WebSockets are built on top of TCP.
-
On Fri, Jun 26, 2009 at 3:25 PM, Michael Nordman micha...@google.comwrote:
On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.comwrote:
Forcing applications to build their own send/ack functionality
On Fri, Jun 26, 2009 at 3:33 PM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 3:25 PM, Michael Nordman micha...@google.comwrote:
On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 2:11 PM, James Robinson
On Fri, Jun 26, 2009 at 3:47 PM, Michael Nordman micha...@google.comwrote:
No. But the difference is each XHR tells you when its been sent and gives
you the response when its received. With this info, apps can rate limit
things. WebSocket.postMessage doesn't tell you when that message has
On 26.6.09 13:52, Michael Nordman wrote:
There isn't a way to determine if the WebSocket is successfully sending
the postMessage data? For all the caller knows, its just backing up and
not going anywhere.
You can't really know data has been successfully sent until you get a response that
On Fri, Jun 26, 2009 at 4:34 PM, Jeff Walden
jwalden+wha...@mit.edujwalden%2bwha...@mit.edu
wrote:
On 26.6.09 13:52, Michael Nordman wrote:
There isn't a way to determine if the WebSocket is successfully sending
the postMessage data? For all the caller knows, its just backing up and
not
On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.com wrote:
Forcing applications to build their own send/ack functionality would be
pretty tragic considering that WebSockets are built on top of TCP.
-
55 matches
Mail list logo
