Unrelated cookies results in 400 Bad request

[dsincl12]

I wanted to try OCaml and Dream and had the following code:

open Ppx_yojson_conv_lib.Yojson_conv.Primitives

type message_object = {
  message : string;
} [@@deriving yojson]

let () =
  Dream.run ~port:3000
  @@ Dream.logger
  @@ Dream.router [
    Dream.get "/" (fun _ ->
      let message = { message = "Hello, OCaml world!"} in
      let message_json = Yojson.Safe.to_string (yojson_of_message_object message) in

      message_json
      |> Dream.json);
  ]

When I visited http://localhost:8080 with Chrome, I expected to see a JSON response but instead I got a 400 Bad request. The log output showed the following:

17.08.23 20:22:42.466 Running at http://localhost:8080 17.08.23 20:22:42.466 Type Ctrl+C to stop 17.08.23 20:22:47.993 dream.http WARN HTTP (::1:55119): Bad request

After some back and forth I tried the request with curl from the command line instead and immediately got the correct response. I tried with Chrome again and still got the bad request response. I then tried the request with Postman and got the correct response again.

After some Googling I saw some comments about cookies and localhost and that clearing all cookies from Chrome had solved the issue. I tried this but it didn't work properly, I could still see that the cookies was there for localhost. After manually deleting the cookies on localhost the request went through and I got the correct response with Chrome as well.

[aantron]

Thank you!

I just tried it locally and was unable to reproduce it. This, together with...

• the lack of stack trace,
• the lack of any Dream code in the example that could trigger an exception or construct a Bad Request response,
• and that the string "Bad request" with that exact capitalization is generated by Dream only in response to http/af errors,

makes me suspect that this is an upstream problem in http/af, and the specific cookie that was being sent was triggering something in http/af. Do you know what the cookie might have been? Are you still able to reproduce this locally, perhaps with the other server that had been running locally at localhost:3000?

cc @anmonteiro in case you might know what could cause this.