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 an async 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:

    1. import { serve } from "https://deno.land/std@$STD_VERSION/http/server.ts";
    2. 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.

    1. async function handler(req: Request): Promise<Response> {
    2. const url = new URL(req.url);
    3. console.log("Path:", url.pathname);
    4. console.log("Query parameters:", url.searchParams);
    5. console.log("Headers:", req.headers);
    6. if (req.body) {
    7. const body = await req.text();
    8. console.log("Body:", body);
    9. }
    10. return new Response("Hello, World!");
    11. }

    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:

    1. function handler(req: Request): Response {
    2. let timer;
    3. const body = new ReadableStream({
    4. async start(controller) {
    5. timer = setInterval(() => {
    6. controller.enqueue("Hello, World!\n");
    7. }, 1000);
    8. },
    9. clearInterval(timer);
    10. },
    11. });
    12. return new Response(body, {
    13. headers: {
    14. "content-type": "text/plain; charset=utf-8",
    15. },
    16. });
    17. }

    ℹ️ 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 a WritableStream object that is attached to the response body ReadableStream object (for example through a TransformStream).

    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.

    1. import { serveTls } from "https://deno.land/std@$STD_VERSION/http/server.ts";
    2. serveTls(handler, {
    3. port: 443,
    4. certFile: "./cert.pem",
    5. keyFile: "./key.pem",
    6. });

    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 supports br for brotli or gzip. 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.