Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deno hangs after a while, serving a static file over HTTPS #10296

Closed
gcocatre opened this issue Apr 21, 2021 · 5 comments · Fixed by #10146
Closed

Deno hangs after a while, serving a static file over HTTPS #10296

gcocatre opened this issue Apr 21, 2021 · 5 comments · Fixed by #10146

Comments

@gcocatre
Copy link

gcocatre commented Apr 21, 2021

I've set up a rudimentary server on AWS EC2 (Debian Linux) running Deno 1.9.1 with an SSL certificate from Let's Encrypt. It simply serves a static HTML file when dealing with a GET request for "/", and returns a 404 for all other requests.

It works fine for a while, and then starts hanging on all requests after a seemingly random amount of time. The code is the following:

import { listenAndServeTLS } from "https://deno.land/std/http/server.ts";

const options = {
  hostname: "www.example.org",
  port: 443,
  certFile: "./keys/cert.pem",
  keyFile: "./keys/key.pem",
};

const index = await Deno.readTextFile("./static/index.html");
const notFound = await Deno.readTextFile("./static/notfound.html");

listenAndServeTLS(options, (req) =>{ 
  let statusCode, content;
  if (req.url === "/") {
    statusCode = 200;
    content = index;
  } else {
    statusCode = 404;
    content = notFound;
  }

  console.log(`${statusCode} ${req.method} ${req.url}`);
  req.respond({
    status: statusCode,
    headers: new Headers({
      "content-type": "text/html",
    }),
    body: content,
  });
});

After the server starts hanging, curl outputs the following (and hangs as well):

*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to www.example.org (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Operation timed out after 300401 milliseconds with 0 out of 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 300401 milliseconds with 0 out of 0 bytes received

Am I doing something wrong? I'm starting a big project based on Deno and this is blocking.

@matt-landers
Copy link

Is it possible that the EC2 instance is spinning down? You can set the minimum instances to 0, so you may occasionally experience a cold start.

I'd start by adding logging to see if the request is making it to the server.

@gcocatre
Copy link
Author

Is it possible that the EC2 instance is spinning down? You can set the minimum instances to 0, so you may occasionally experience a cold start.

I have an SSH session open on the server and it remains responsive at all times while that happens.

I'd start by adding logging to see if the request is making it to the server.

As shown in my code, Deno outputs all requests it receives. When it starts hanging, it stops outputting anything. Where else would you suggest I look?

@AaronO
Copy link
Contributor

AaronO commented Apr 22, 2021

@gcocatre I think this is a duplicate of #9692 and #10049. So #10146 should also fix your issue

@gcocatre
Copy link
Author

@AaronO I'm not entirely sure it's the same issue. The static files I use are only 6 kilobytes. Moreover, I've been running version 1.7.0 and I still get the same error, albeit perhaps less frequently.

In any case, I didn't realise it when I posted this issue, but am I not supposed to run Deno's newly released native API anyway?

piscisaureus added a commit to piscisaureus/deno that referenced this issue May 10, 2021
…ite half"

using tokio::io::split() to allow concurrent Conn#read() and
Conn#write() calls without one blocking the other. However, this
introduced a bug: outgoing data gets discarded when the TLS stream is
gracefully closed, because the read half is closed too early, before all
TLS control data has been received.

Fixes: denoland#9692
Fixes: denoland#10049
Fixes: denoland#10296
Fixes: denoland/std#750
piscisaureus added a commit to piscisaureus/deno that referenced this issue May 10, 2021
denoland#10146)

In denoland#9118, TLS streams were split into a "read half" and a "write half"
using tokio::io::split() to allow concurrent Conn#read() and
Conn#write() calls without one blocking the other. However, this
introduced a bug: outgoing data gets discarded when the TLS stream is
gracefully closed, because the read half is closed too early, before all
TLS control data has been received.

Fixes: denoland#9692
Fixes: denoland#10049
Fixes: denoland#10296
Fixes: denoland/std#750
@ry
Copy link
Member

ry commented May 11, 2021

Reopening. Fix revert in #10595. False alarm

@ry ry reopened this May 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants