The API tries to leverage as much of the web standards as is possible as well as tries to be simple and straightforward.
To start a HTTP server on a given port, you can use the serve
function from
. This function takes a
handler function that will be called for each incoming request, and is expected
to return a response (or a promise resolving to a response).
Here is an example of a handler function that returns a “Hello, World!” response for each request:
ℹ️ The handler can also return a
Promise<Response>
, which means it can be anasync
function.
To then listen on a port and handle requests you need to call the serve
function from the https://deno.land/std@$STD_VERSION/http/server.ts
module,
passing in the handler as the first argument:
import { serve } from "https://deno.land/std@$STD_VERSION/http/server.ts";
serve(handler);
By default serve
will listen on port 8000
, but this can be changed by
passing in a port number in the second argument options bag:
This same options bag can also be used to configure some other options, such as the hostname to listen on.
Inspecting the incoming request
Most servers will not answer with the same response for every request. Instead they will change their answer depending on various aspects of the request: the HTTP method, the headers, the path, or the body contents.
async function handler(req: Request): Promise<Response> {
const url = new URL(req.url);
console.log("Path:", url.pathname);
console.log("Query parameters:", url.searchParams);
console.log("Headers:", req.headers);
if (req.body) {
const body = await req.text();
console.log("Body:", body);
}
return new Response("Hello, World!");
}
Most servers also do not respond with “Hello, World!” to every request. Instead they might respond with different headers, status codes, and body contents (even body streams).
Here is an example of returning a response with a 404 status code, a JSON body, and a custom header:
Response bodies can also be streams. Here is an example of a response that returns a stream of “Hello, World!” repeated every second:
function handler(req: Request): Response {
let timer;
const body = new ReadableStream({
async start(controller) {
timer = setInterval(() => {
controller.enqueue("Hello, World!\n");
}, 1000);
},
clearInterval(timer);
},
});
return new Response(body, {
headers: {
"content-type": "text/plain; charset=utf-8",
},
});
}
ℹ️ Note the
cancel
function here. This is called when the client hangs up the connection. This is important to make sure that you handle this case, as otherwise the server will keep queuing up messages forever, and eventually run out of memory.⚠️ Beware that the response body stream is “cancelled” when the client hangs up the connection. Make sure to handle this case. This can surface itself as an error in a
write()
call on aWritableStream
object that is attached to the response bodyReadableStream
object (for example through aTransformStream
).
WebSocket support
Deno can upgrade incoming HTTP requests to a WebSocket. This allows you to handle WebSocket endpoints on your HTTP servers.
To upgrade an incoming Request
to a WebSocket you use the
Deno.upgradeWebSocket
function. This returns an object consisting of a
and a web standard WebSocket
object. This response must be returned
from the handler for the upgrade to happen. If this is not done, no WebSocket
upgrade will take place.
Because the WebSocket protocol is symmetrical, the WebSocket
object is
identical to the one that can be used for client side communication.
Documentation for it can be found
on MDN.
WebSockets are only supported on HTTP/1.1 for now. The connection the WebSocket was created on can not be used for HTTP traffic after a WebSocket upgrade has been performed.
ℹ️ To use HTTPS, you will need a valid TLS certificate and a private key for your server.
To use HTTPS, use serveTls
from the
https://deno.land/std@$STD_VERSION/http/server.ts
module instead of serve
.
This takes two extra arguments in the options bag: certFile
and keyFile
.
These are paths to the certificate and key files, respectively.
import { serveTls } from "https://deno.land/std@$STD_VERSION/http/server.ts";
serveTls(handler, {
port: 443,
certFile: "./cert.pem",
keyFile: "./key.pem",
});
HTTP/2 support
HTTP/2 support it “automatic” when using the native APIs with Deno. You just need to create your server, and the server will handle HTTP/1 or HTTP/2 requests seamlessly.
As of Deno 1.20, the HTTP server has built in automatic compression of response bodies. When a response is sent to a client, Deno determines if the response body can be safely compressed. This compression happens within the internals of Deno, so it is fast and efficient.
Currently Deno supports gzip and brotli compression. A body is automatically compressed if the following conditions are true:
- The request has an
Accept-Encoding
header which indicates the requestor supportsbr
for brotli orgzip
. Deno will respect the preference of the in the header. - The response includes a
Content-Type
which is considered compressible. (The list is derived from with the actual list in the code.) - The response body is greater than 20 bytes.
When the response body is compressed, Deno will set the
header to reflect the encoding as well as ensure the
Vary
header
is adjusted or added to indicate what request headers affected the response.
When is compression skipped?
In addition to the logic above, there are a few other reasons why a response won’t be compressed automatically:
- The response body is a stream. Currently only static response bodies are supported. We will add streaming support in the future.
- The response contains a
Content-Encoding
header. This indicates your server has done some form of encoding already. - The response contains a
Content-Range
header. This indicates that your server is responding to a range request, where the bytes and ranges are negotiated outside of the control of the internals to Deno.
What happens to an ETag
header?
When you set an
ETag
that is
not a weak validator and the body is compressed, Deno will change this to a weak
validator (W/
). This is to ensure the proper behavior of clients and
downstream proxy services when validating the “freshness” of the content of the
response body.
Lower level HTTP server APIs
If you do want to learn more about the low level HTTP server APIs though, you can read more about them here.