The node:http and deno serve APIs silently drop the fragment part of http get/request/...

[BerndAmend]

Version: Deno 2.5.6
Node Version: v25.2.1

The node:http and deno serve APIs silently drop the fragment part of http get/request/...
For the fetch API this is expected, but not for node:http and deno serve.

I noticed this issue while implementing WebDav with deno.
The test suites (litmus) require the server to reject invalid http requests (in this case containing a #) which is not possible in deno, since they are silently dropped from http requests. I think this is in general undesired behavior.

Source: https://github.com/BerndAmend/deno-serve-fragment-test

The Web server created either using node:http

import * as http from "node:http";

http.createServer(function (req, res) {
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.end(req.url);
}).listen(8000);

or deno serve

export default {
  async fetch(req: Request) {
    return new Response(req.url, { status: 200 });
  },
};

Client Code

import * as http from "node:http";

console.log(
  "send: " +
    http.get({ hostname: "localhost", port: 8000, path: "/f#f" }, (res) => {
      res.on("data", (chunk) => console.log("received: " + chunk.toString()));
    }).path,
);

Node returns the expected output

$ node node_server.ts 
$ node client.ts
send: /f#f
received: /f#f

Deno does not

$ deno run -N node_server.ts 
$ node client.ts
send: /f#f
received: /f

$ deno serve deno_server.ts
$ node client.ts
send: /f#f
received: http://localhost:8000/f

The client side API is also incorrect in deno

$ node node_server.ts 
$ deno run -N client.ts
send: /f#f
received: /f

[marvinhagemeister]

What an odd choice by the WebDAV team. The URL fragment is never supposed to be processed by the server and it should never receive that. If it does receive it, it would mean that the client that send the request has a bug. The networking stack in Deno is built around the hyper Rust lib (relevant issue: hyperium/http#127) which doesn't support this either.

It's super unlikely that we're ever going to change this behaviour as this is more a client problem, not a server one.

[BerndAmend]

I never heard of a web server that silently modifies the request without any way to detect it.
I also don't think it's "working as designed" because it deviates from the reference implementation node:http.
If this is really "as designed" it should be documented (https://docs.deno.com/api/node/http/) as a deviation from node:http, it took me a while to discover this odd behavior.
It also makes implementing protocols that require rejecting requests that contain fragments impossible.

[bartlomieju]

I asked @littledivy to investigate