`c.req.url` is always http

[hilja]

This might be how it should work, but let me confirm.

c.req.url is always http, even on https requests:

app.get('/foo', c => {
  // Always http, in prod too
  console.log(c.req.url)
  console.log(c.req.raw.url)
  return c.text('OK')
})

I'm on fly.io, basically a proxy that handles my ssl (plus other things). But in Hono I always get the url as http, and my JWT verification fails. It's easy to fix but I somehow expected the proto to be the same as the original request.

Here's my serve:

serve({
  fetch: app.fetch,
  port: Number(PORT),
})

More details on my use-case

This is specifically a request from QStash. It's a queue thing, works something like this:

curl -XPOST \
    -H 'Authorization: Bearer <QSTASH_TOKEN>' \
    -H "Content-type: application/json" \
    -d '{ "hello": "world" }' \
    'https://qstash.upstash.io/v2/publish/https://example.com/foo'

Notice the url after the QStash endpoint, that's the callback URL that Hono is listening to, and which I've set it to https. Here's the headers QStash sends:

{
  'accept-encoding': 'gzip',
  authorization: 'Basic xxx',
  'content-length': '203',
  'content-type': 'application/json',
  host: 'example.com/foo',
  'upstash-caller-ip': 'xxx.xx.xx.xx',
  'upstash-message-id': 'msg_xxx',
  'upstash-retried': '0',
  'upstash-signature': 'xxx',
  'user-agent': 'Upstash-QStash',
  'x-forwarded-for': 'x.xxx.xxx.xxx',
  'x-forwarded-host': 'example.com/foo',
  'x-forwarded-proto': 'https'
}

I'm guessing it would be https if I used the https server like shown in the docs:

import { createServer } from 'node:https'
serve({
  fetch: app.fetch,
  createServer: createServer,
  serverOptions: { /* keys */},
})

But I don't need to because of fly.

Correct me if I'm mistaken but it feels like Hono should use x-forwarded-proto to set the correct proto?

[m4nuC]

Any luck on that one ? I have the same issue

[seep]

We're seeing this as well with https.createServer.

[seep]

This line seems to be the issue: https://github.com/honojs/node-server/blob/main/src/request.ts#L120 The request shim has the HTTP protocol hard coded.

[yusukebe]

@hilja Thanks for raising the issue.

Hi @usualoma , as @seep mentioned, I think we can fix the line. Can you take a look?

[seep]

If it helps, I was able to work around this by pulling the IncomingMessage object out of the request and checking incoming.socket.encrypted. I think you can do the same here for the fix. When using https.createServer the socket will be an instance of tls.TLSSocket instead of net.Socket. For reference: https://nodejs.org/api/tls.html#tlssocketencrypted

[usualoma]

Hi @hilja Thanks for creating the issue.

Hi @seep Thanks for the reference info.

Indeed, when using 'node:http2' or 'node:https', it certainly looks better to be https:. I will create a PR for the change.

As for the x-forwarded-proto, I think it should be handled on the application side. Or if there are a lot of requests, we could provide a hook point that can be rewritten. Anyway, I think it is better not to handle x-forwarded-proto implicitly.

[usualoma]

Created #155

[mattes3]

To handle x-forwarded-proto correctly, I used this hack here:

app.use(async (c, next) => {
    const forwardedProto = c.req.header('x-forwarded-proto');
    if (forwardedProto === 'https') {
        Object.defineProperty(c.req, 'url', {
            value: c.req.url.toString().replace('http:', 'https:'),
            configurable: true,
        });
    }

    await next();
});

Looks a bit heavy-handed, but it works.

[jraoult]

@mattes3 @yusukebe just stumbled upon that today, while reviewing our migration from Koa to Hono. Our app runs behind reverse proxies (Heroku's router and Cloudflare's) with TLS terminating there. Behind the proxy, we use http (for ease of configuration mainly), which means that even with #155, the HonoRequest's url has the http protocol. That generated more problems for us down the line. The only way to get this working correctly is by using the value set by these proxies in `x-forwarded-proto.

My point is that x-forwarded-proto should also be handled at Hono's level and affect the URL's protocol, probably around here:

node-server/src/request.ts

Lines 192 to 200 in 7f327f5

	let scheme: string
	if (incoming instanceof Http2ServerRequest) {
	scheme = incoming.scheme
	if (!(scheme === 'http' || scheme === 'https')) {
	throw new RequestError('Unsupported scheme')
	}
	} else {
	scheme = incoming.socket && (incoming.socket as TLSSocket).encrypted ? 'https' : 'http'
	}

Here's what Koa is doing for comparison: https://github.com/koajs/koa/blob/cb22d8dcdeb7c0e4e1bdee5eaa5be183ef23a1f2/lib/request.js#L388-L405

[yusukebe]

Hi @jraoult

My point is that x-forwarded-proto should also be handled at Hono's level and affect the URL's protocol, probably around here:

I think it's important how we define what "Hono's level" is. Is it in this Node.js Adapter? Or middleware for Hono app like #146 (comment) ?

We discuss this at #268