Dart strings with embedded '\0' characters cannot be faithfully
represented as a C string.
This change adds Dart_StringToBytes to the Dart API. This function
converts a Dart string to array of UTF-8 code units and returns a
length. Builtin::PrintString now calls Dart_StringToBytes instead of
Dart_StringToCString and, for I/O, fwrite is called instead of fprintf
with the string format specifier.
BUG=1098
Review URL: https://chromiumcodereview.appspot.com//10306002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@7260 260f80e4-7a28-3924-810f-c04153c831b5
The web socket client is a implemented as a class which is
created from from a HTTP client connection. This way it is
independent from the HTTP client and is just using the HTTP
client.
The protocol handling is mainly re-using the code from the web
socket server.
Change the handling of setting an onNoPendingWrites handler on a
socket output stream. Now setting a new onNoPendingWrites handler
will trigger a callback when there is no pending data to be
written.
Add socket detaching to the HTTP client as well. Add the ability
to get any unparsed data read from the socket for processing
after the protocol upgrade.
R=ager@google.com, ajohnsen@google.com, vsm@google.com, jacobr@google.com
BUG=dart:2001
TEST=tests/standalone/io/web_socket_test.dart
Review URL: https://chromiumcodereview.appspot.com//10262031
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@7224 260f80e4-7a28-3924-810f-c04153c831b5
The HTTP headers object in request and response objects is now marked
as non-mutable when it cannot be changed. An exception will be thrown
if trying to mutate headers when they are not mutable.
Postponed the sending of the headers until either the first byte of
body data is sent or the empty body is indicated. This is to allow
getting the output stream object and still be able to set headers
until the actual body is touched.
Added checking of the number of bytes of body data transmitted when an
explicit content length is specified.
R=ajohnsen@google.com
BUG=none
TEST=tests/standalone/src/io/HttpHeadersState.dart,tests/standalone/src/io/HttpContentLengthTest.dart
Review URL: https://chromiumcodereview.appspot.com//10232006
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@7010 260f80e4-7a28-3924-810f-c04153c831b5
This implements the web socket protocol as a request handler for
the HTTP server. The HTTP server have been updated with the
ability of getting the socket when a HTTP upgrade request is
processed. This way the web socket implementation is not builtin
to the HTTP server.
The API on the server is:
interface WebSocketConnection {
void set onMessage(void callback(Object message));
void set onClosed(void callback(int status, String reason));
void set onError(void callback(e));
send(Object message);
close([int status, String reason]);
}
This API currently does not have any streaming but collects the
entire message before invoking the onMessage callback. The
current browser web socket API
(http://dev.w3.org/html5/websockets/) works the same way. The
underlying web socket protocol can have unbounded messages so
long term this probably have to change. But for now the only
likely client for a web socket server is a browser.
Currently this is missing tests. The implementation has been
tested by running the WebSocketTest.dart script and connecting
using a browser. This testing have been done using Chrome 19 and
Firefox 11.
I will be adding tests in separate change lists.
The SHA-1 and base 64 code (initially written by
ajohnsen@google.com) can be removed when these algorithms is
available in the dart:crypto.
R=ager@google.com, ajohnsen@google.com, vsm@google.com, jacobr@google.com
BUG=dart:2001
TEST=none
Review URL: https://chromiumcodereview.appspot.com//10205012
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6998 260f80e4-7a28-3924-810f-c04153c831b5
1. Change the argument on all onError handlers from Exception to
Dynamic
2. Throw an exception if an error ocours and there is no error handler
present for handling it.
For sockets there is the complication that an error on a socket is
reported to the socket error handler, and each of the stream error
handlers. The solution to this is to throw an exception if there was
no error handler on either the socket or one of the streams.
Fixed a number of bugs in tests revealed by errors no longer being
silently ignored.
R=ager@google.com
BUG=none
TEST=tests/standalone/src/io/*
Review URL: https://chromiumcodereview.appspot.com//10173024
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6994 260f80e4-7a28-3924-810f-c04153c831b5
Fix for issue 1598.
Lexical scope comes before inherited names. Also, Static members
are not inherited and are not visible in subclasses.
Code in the subclass (or any other code for that matter) has to
qualify the names of these members with the class name.
We had a few tests that were wrong and only passed in the VM because
this was not implemented correctly.
Also had to fix code in frog and dartdoc.
I hope I ran enough tests. I built an all.deps tree using tools/build.py from the root directory, which brought up the frog and dartdoc issues.
Tested:
tools/test.py --compiler=dart2js --runtime=drt
tools/test.py -c none -r drt
tools/test.py -c frog -r drt
tools/test.py -r vm
Review URL: https://chromiumcodereview.appspot.com//10115005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6698 260f80e4-7a28-3924-810f-c04153c831b5
NOTE: This is a breaking change.
The onRequest callback on the HTTP server have been removed in favor
of the ability to register handlers. A handler can be either a
function or an instance of a class which implements a specific
interface. Each handler registration has a regular expression which is
matched against the request path.
There is also a default handler which can be set to handle all
requests which is not matched by any of the registered patterns. If
there is no default handler explicitly set there is a builtin one
which will just return 404 status.
Currently the method is not considered in the matching.
R=ager@google.com, ajohnsen@google.com
BUG=none
TEST=tests/standalone/src/io/HttpServerHandlerTest.dart
Review URL: https://chromiumcodereview.appspot.com//10119005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6683 260f80e4-7a28-3924-810f-c04153c831b5
Map<String, String> env = new Platform().environment();
Unfortunately, this is a bit hard to test at this point. I
will move on to implement support for providing an environment
to processes that are started. At that point we can test it
properly.
Another follow-up change will be to remove the instantiation
for Platform. I would like this to be just
Map<String, String> env = Platform.environment();
R=sgjesse@google.com
BUG=dartbug.com/752
TEST=
Review URL: https://chromiumcodereview.appspot.com//10112002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6646 260f80e4-7a28-3924-810f-c04153c831b5
The HTTP parser now recognized both HTTP/1.1 and HTTP/1.0 in
request and response headers. The only difference between the
handling of HTTP 1.1 and HTTP 1.0 is in the decection of
persistent connections. For HTTP 1.1 persistent connections are
the default and for HTTP 1.0 persistent connections are speficified
throught the "Connection: Keep-Alive" header.
Removed the getters and setters for keepAlive from all the
interfaces. They are not of much use and persistent connection
handling should be transparent. The HTTP client currently always
sends requests using HTTP 1.1 and in the reare cases where one wants the
connection to be closed after the request adding the
header "Connection: close" should work.
With this change using wget to get resources from the chat server.
R=ajohnsen@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//10008083
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6509 260f80e4-7a28-3924-810f-c04153c831b5
First attempt at implementing a higher-level API for processes.
Add a startNonInteractive constructor that takes a callback which
is called with the exit code and the complete stdout and stderr
when the process terminates.
Let me know what you think. This obviously needs at least tests.
Not entirely sure what I think about the interface in the first
place.
R=sgjesse@google.com
BUG=1689
TEST=
Review URL: https://chromiumcodereview.appspot.com//9863015
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6499 260f80e4-7a28-3924-810f-c04153c831b5
sgjesse@google.com