Releases: ponylang/http_server
0.6.3
0.6.2
0.6.1
Rename upgrade to upgrade_protocol
To allow changing the TCP handler of a running HTTP connection, Session specifies a method upgrade_protocol, which should be implemented by the concrete classes. The implementation used by the actual HTTP server had an implementation for this feature, but the method was called upgrade. As Session provides a default implementation for upgrade_protocol, this wasn't caught. By renaming the implementation it's now possible to use the new feature to change the handler to a custom handler to handle for example WebSocket connections.
[0.6.1] - 2024-04-02
Fixed
- Implement the correct method in the server_connection (PR #78)
0.6.0
Add Session.upgrade_protocol behaviour
This can be used to upgrade the underlying TCP connection to a new incompatible protocol, like websockets.
Calling this new behaviour allows this TCP connection to be upgraded to another handler, serving another protocol (e.g. WebSocket).
Note that this method does not send an HTTP Response with a status of 101. This needs to be done before calling this behaviour. Also, the passed in notify will not have its methods accepted or connected called, as the connection is already established.
After calling this behaviour, this session and the connected Handler instance will not be called again, so it is necessary to do any required clean up right after this call.
See:
[0.6.0] - 2024-03-12
Added
- Add possibility to upgrade the current session to a new TCP handler (PR #75)
0.5.0
Ensure Content-Length is set for all Responses that need it
Previously responses without explicitly added Content-Length didn't add that header with a 0 value. This made some HTTP clients hang.
Now all responses built with this library will have a default Content-Length header set, unless marked with Transfer-Encoding: chunked
Added ResponseBuilderHeaders.set_content_length(content_length: USize)
This way it is more convenient to set a content-length from a numeric value. E.g. from the size of a prepared array to be passed as HTTP body:
let body = "I am a teapot"
let response =
Responses.builder()
.set_status(StatusOK)
.set_content_length(body.size())
.add_header("Content-Type", "text/plain")
.finish_headers()
.add_chunk(body)
.build()Added BuildableResponse.delete_header(header_name: String)
Previously it was not possible to delete a header, once set it was permanent. No it is possible to delete a header e.g. in multi-stage processing of a HTTP response.
ResponseBuilderBody.add_chunk() now takes a ByteSeq instead of Array[U8] val
This allows to pass String val as well as Array[U8] val to add_chunk.
let response = Responses.builder()
.set_content_length(7)
.finish_headers()
.add_chunk("AWESOME")
.build()BuildableResponse.create() now only takes a Status and optionally a Version
The logic applied to set content_length and transfer_encoding from the constructor parameters was a bit brittle, so it got removed. Use both set_content_length(content_length: USize) and set_transfer_encoding(chunked: (Chunked | None)) to set them:
let body = "AWESOME"
let response = BuildableResponse
.create(StatusOK)
.set_content_length(body.size())
.set_header("Content-Type", "text/plain")Response.transfer_coding() changed to .transfer_encoding()
The wording now is now equal to the actual header name set with this method.
BuildableResponse.set_transfer_coding() changed to .set_transfer_encoding()
Following the Response trait.
[0.5.0] - 2024-02-18
Fixed
- Ensure Content-Length is set for all Responses that need it (PR #74)
Added
- Added
ResponseBuilderHeaders.set_content_length(content_length: USize)(PR #74) - Added
BuildableResponse.delete_header(header_name: String)(PR #74)
Changed
ResponseBuilderBody.add_chunk()now takes aByteSeqinstead ofArray[U8] val(PR #74)BuildableResponse.create()now only takes aStatusand aVersion(PR #74)BuildableResponse.set_transfer_coding()changed to.set_transfer_encoding()(PR #74)-
Response.transfer_coding()changed to.transfer_encoding()(PR #74)
0.4.6
0.4.5
0.4.4
0.4.3
0.4.2
Updated default connection heartbeat length
Previously, the default connection heartbeat was incorrectly set to 1ms. We've updated it to the value it was intended to be: 1000ms.
Sending a heartbeat every millisecond was excessive, and this change should improve performance slightly.
[0.4.2] - 2022-08-26
Fixed
- Update default connection heartbeat length (PR #47)