There was a number of issues in relation to using the HTTP method HEAD
* The HTTP parser did not parse HEAD correctly
* HEAD respoonse could not have a content length and empty body
* The client could not receive a HEAD response with content length an empty body
I the server we support writing to the output stream when replying to a head request.
They should now be fixed and a test for HEAD have been added
R=ager@google.com
BUG=dart:3205
TEST=tests/standalone/io/http_head_test.dart, tests/standalone/io/http_parser_test.dart
Review URL: https://chromiumcodereview.appspot.com//10449020
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@7986 260f80e4-7a28-3924-810f-c04153c831b5
This change adds the list field cookies to all requests and
responses.
For HttpRequest the cookie list will have all the cookies set by
the client in its HttpClientRequest cookie list. These cookies
are passed through the "Cookie" HTTP header.
For HttpClientResponse the cookie list will have all the cookies
set by the server in the HttpResponse cookie list. These cookies
are passed through the "Set-Cookie" HTTP header.
The parsing of the "Cookie" and "Set-Cookie" headers try to
follow RFC 6265.
This change does not add a cookie jar in the http client with
cookie policy for automatic cookie handling.
R=ager@google.com, ajohnsen@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//10414076
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@7943 260f80e4-7a28-3924-810f-c04153c831b5
This adds parsing of HTTP headers of the form:
Name=value; parameter1=value1; parameter2=value2
Specialize the implemented header value class into a content type
class.
One could argue whether the "synchronization" between the string
representation and the content type object representation is the best
way, but if the exposed parameters map should just be the standard map
implementation there is no way of detection changes,
R=ager@google.com, ajohnsen@google.com
BUG=dart:2045
TEST=tests/standalone/io/http_test.dart, tests/standalone/io/http_headers_test.dart
Review URL: https://chromiumcodereview.appspot.com//10407002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@7851 260f80e4-7a28-3924-810f-c04153c831b5
Redirection is implemented by re-using the same HttpClientConnection
object for several request/response pairs. There is s redirect method
on the HttpClientConnection object for manual redirection. The
HttpClientConnection object also has properties followRedirects and
maxRedirects to configure automatic redirect handling.
When redirection happen the HttpClientConnection will collect the
redirection history for client einspection and for redirect loop
detection.
R=ajohnsen@google.com, ager@google.com
BUG=none
TEST=tests/standalone/io/http_redirect_test.dart
Review URL: https://chromiumcodereview.appspot.com//10386024
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@7415 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
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
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
If any type of HTTP connection encounters an error writing additional
data is an error. However in many cases getting exceptions from writes
in this situation is inconvenient.
With this change any data written will be silently discarded after an
error have occoured. The onError will always be called and the user of
the library have the ability to stop generating output data as soon as
possible.
Currently this is default behaviour with no option for changing it.
R=ajohnsen@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9958059
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@6089 260f80e4-7a28-3924-810f-c04153c831b5
The socket errors and HTTP parser errors are now handled by the
HTTP library and propagated to the related onError callback.
For HttpClient there is no onError on the HttpClient object
itself. Errors on active connections (including connection
errors) are reported on the HttpClientConnection. Errors on
connections sitting in the keep alive pool are handled by just
closing the connection and removing it from the pool. Errors on
the HttpClientConnection are also reported through the onError
callbacks on any active streams.
I am not particulair happy of the way errors are propagated to
the active streams but that can be refactored later.
Added more checks and tests to the HTTP parser.
R=ager@google.com, ajohnsen@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9834008
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5768 260f80e4-7a28-3924-810f-c04153c831b5
The message content detection and handling should now be more
correct and according to the specification (RFC 2616 section 4.3).
* Requests with no Content-Length and no Transfer-Encoding have no message body
* Responses with status code 1xx, 204 and 304 have no message body
* Responses which are responses to HEAD requests have no message body
Also added support for detecting chunk-extensions and ignoring these.
R=ajohnsen@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9812005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5722 260f80e4-7a28-3924-810f-c04153c831b5
Changed the onError callback for sockets to take an exception argument.
First area to report errors for is name resolution.
Changed the IP address resolution from being synchronous with the
creation of the socket to being asynchronous thsough a lookup
service running on a native port. Currently this lookup service
is static on the socket class as we need to call it from a
factory method. We should probably add a separate name lookup
service at some point.
R=ager@google.com
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com//9699017
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@5640 260f80e4-7a28-3924-810f-c04153c831b5
ajohnsen@google.com