|
1 | 1 | # Changelog |
2 | 2 |
|
| 3 | +## 0.6.0 (2016-03-09) |
| 4 | + |
| 5 | +* Feature / BC break: The `Request` and `Response` objects now follow strict |
| 6 | + stream semantics and their respective methods and events. |
| 7 | + (#116, #129, #133, #135, #136, #137, #138, #140, #141 by @legionth and |
| 8 | + #122, #123, #130, #131, #132, #142 by @clue) |
| 9 | + |
| 10 | + This implies that the `Server` now supports proper detection of the request |
| 11 | + message body stream, such as supporting decoding chunked transfer encoding, |
| 12 | + delimiting requests with an explicit `Content-Length` header |
| 13 | + and those with an empty request message body. |
| 14 | + |
| 15 | + These streaming semantics are compatible with previous Stream v0.5, future |
| 16 | + compatible with v0.5 and upcoming v0.6 versions and can be used like this: |
| 17 | + |
| 18 | + ```php |
| 19 | + $http->on('request', function (Request $request, Response $response) { |
| 20 | + $contentLength = 0; |
| 21 | + $request->on('data', function ($data) use (&$contentLength) { |
| 22 | + $contentLength += strlen($data); |
| 23 | + }); |
| 24 | + |
| 25 | + $request->on('end', function () use ($response, &$contentLength){ |
| 26 | + $response->writeHead(200, array('Content-Type' => 'text/plain')); |
| 27 | + $response->end("The length of the submitted request body is: " . $contentLength); |
| 28 | + }); |
| 29 | + |
| 30 | + // an error occured |
| 31 | + // e.g. on invalid chunked encoded data or an unexpected 'end' event |
| 32 | + $request->on('error', function (\Exception $exception) use ($response, &$contentLength) { |
| 33 | + $response->writeHead(400, array('Content-Type' => 'text/plain')); |
| 34 | + $response->end("An error occured while reading at length: " . $contentLength); |
| 35 | + }); |
| 36 | + }); |
| 37 | + ``` |
| 38 | + |
| 39 | + Similarly, the `Request` and `Response` now strictly follow the |
| 40 | + `close()` method and `close` event semantics. |
| 41 | + Closing the `Request` does not interrupt the underlying TCP/IP in |
| 42 | + order to allow still sending back a valid response message. |
| 43 | + Closing the `Response` does terminate the underlying TCP/IP |
| 44 | + connection in order to clean up resources. |
| 45 | + |
| 46 | + You should make sure to always attach a `request` event listener |
| 47 | + like above. The `Server` will not respond to an incoming HTTP |
| 48 | + request otherwise and keep the TCP/IP connection pending until the |
| 49 | + other side chooses to close the connection. |
| 50 | + |
| 51 | +* Feature: Support `HTTP/1.1` and `HTTP/1.0` for `Request` and `Response`. |
| 52 | + (#124, #125, #126, #127, #128 by @clue and #139 by @legionth) |
| 53 | + |
| 54 | + The outgoing `Response` will automatically use the same HTTP version as the |
| 55 | + incoming `Request` message and will only apply `HTTP/1.1` semantics if |
| 56 | + applicable. This includes that the `Response` will automatically attach a |
| 57 | + `Date` and `Connection: close` header if applicable. |
| 58 | + |
| 59 | + This implies that the `Server` now automatically responds with HTTP error |
| 60 | + messages for invalid requests (status 400) and those exceeding internal |
| 61 | + request header limits (status 431). |
| 62 | + |
3 | 63 | ## 0.5.0 (2017-02-16) |
4 | 64 |
|
5 | 65 | * Feature / BC break: Change `Request` methods to be in line with PSR-7 |
|
0 commit comments