When a service yields a task that takes a long time to produce a response (see /slow in the code below), the Blaze backend will drop the socket after idleTimeout has elapsed. The Jetty backend:

1. Keeps the connection open for 30 seconds, ignoring idleTimeout.
2. Then returns a 200 OK with no body.

import scala.concurrent.duration._

import scalaz.concurrent._

import org.http4s.dsl._
import org.http4s.server._

object JettyTest extends App {
  val service = HttpService {
    case GET -> Root / "slow" => for {
      _    <- Task.delay { Thread.sleep(45*1000) }
      resp <- InternalServerError("finally!")
    } yield resp

    case GET -> Root / "fail" => Task.fail(new RuntimeException)
  }

  val js = org.http4s.server.jetty.JettyBuilder
    .withIdleTimeout(1.second)
    .bindHttp(8080, "0.0.0.0")
    .mountService(service)

  val bs = org.http4s.server.blaze.BlazeBuilder
    .withIdleTimeout(1.second)
    .bindHttp(8180, "0.0.0.0")
    .mountService(service)

  js.run
  bs.run
}

Using http4s 0.8.2.

https://github.com/http4s/http4s/pull/5215/checks?check_run_id=3641814955#step:10:3323, among others

If I use a Router where the prefix includes a forward slash, I would expect the whole prefix to be stripped from the request before matching on the inner routes. More specifically, if I have routes like this:

org.http4s.server.Router(
  "pref-a/pref-b" -> myRoutes
)

And I make a request to pref-a/pref-b/my-resource, I would expect to be able to match Root / "my-resource" within myRoutes.

This appears to work as expected if I use blaze as the server, but if I use jetty it only removes the first segment of the prefix, meaning that I have to match Root / "pref-b" / "my-resource".

Not sure how good a job I did explaining that, so I have reproduced it in this repo. It spins up jetty on 8080 and blaze on 8081 serving the same routes. You can see that we get the expected behaviour from blaze but not from jetty.

==> X org.http4s.jetty.server.JettyServerSuite.ChannelOptions should route requests on the service executor  8.35s java.io.IOException: Server returned HTTP response code: 500 for URL: http://127.0.0.1:40987/thread/routing
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1897)
    at sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:92)
    at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1487)
    at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1485)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:784)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1484)
    at java.net.URL.openStream(URL.java:1093)
    at scala.io.Source$.fromURL(Source.scala:144)
    at org.http4s.jetty.server.JettyServerSuite.$anonfun$get$1(JettyServerSuite.scala:69)
    at blocking @ org.http4s.jetty.server.JettyServerSuite.get(JettyServerSuite.scala:71)
    at map @ org.http4s.jetty.server.JettyServerSuite.$anonfun$new$1(JettyServerSuite.scala:86)
    at flatMap @ munit.CatsEffectAssertions.assertIO(CatsEffectAssertions.scala:52)

https://github.com/http4s/http4s/runs/4141739369?check_suite_focus=true

When sending a GET request (no body) using the Jetty client sometimes it sends multiple network-level requests and uses Transfer-Encoding: chunked. From local testing manually setting content-length to 0 means this issue does not occur.

I've tried to produce a test with TestContext from cats-effect but trying to use the Jetty client leads to a deadlock (I can create it and tear it down with no issues).

If I had to guess I would say this is due to a race between the Jetty request being sent and the content for that request being populated, the lines are here:

https://github.com/http4s/http4s/blob/30798ab62e4d4739249692e7e80a8831654aa28a/jetty-client/src/main/scala/org/http4s/client/jetty/JettyClient.scala#L28

If the request sends (jReq.send(rl)) before the delayed content has written (dcp.write(req), dcp is a StreamRequestContentProvider) the request will be chunked.

Possibly just inverting these lines might mean the race is less likely? Unless are that way around for a reason (send before write).

http4s version: 0.21.0-M5. Sorry, only just realised this isn't the latest but I think there have been no changes between versions.

We can bring our own HttpConfiguration, but we can't configure the one that's there. JettyBuilder should have something like:

transformJettyHttpConfiguration(f: HttpConfiguration => HttpConfiguration)