ijpiantanida / talkback

A simple HTTP proxy that records and playbacks requests
MIT License
284 stars 41 forks source link

Can't use host headers? #27

Closed floydjdx closed 2 years ago

floydjdx commented 5 years ago

Why do you delete host from headers? Can you make this optional?

ijpiantanida commented 5 years ago

Keeping the host header would make tapes specific to where talkback is running (port & host), which is not very useful.

What do you need the host header for?

floydjdx commented 5 years ago

The system I am working with extracts some information from the host header.

ijpiantanida commented 5 years ago

The host removal only affects tape matching.

The request that will be made to the downstream service will contain its own host header (set to the host property with which you started talkback).

floydjdx commented 5 years ago

Right, but I can only set one host property when I start talkback and my requests use different host headers depending on the request.

ijpiantanida commented 5 years ago

Talkback only fronts one service at a time, since it wouldn't have information to know where to route a request in case of multiple hosts.

If you're making requests to multiple services and you want to front them with talkback, you should start one talkback instance per service.

Something like this:

const service1 = talback({
  ...baseOpts,
  host: "https://my-service1.com",
  port: 8081,
  path: baseOpts.path + "/service1"
})
service1.start()

const service2 = talback({
  ...baseOpts,
  host: "https://my-service2.com",
  port: 8082,
  path: baseOpts.path + "/service2"
})
service2.start()
floydjdx commented 5 years ago

That won't work because all requests are meant to be sent to the same service but with different host headers depending on the user whose data is being requested.

brandonc commented 3 years ago

@ijpiantanida I believe @Floydjd is referring to https://github.com/ijpiantanida/talkback/blob/master/src/request-handler.ts#L125 where the host header is deleted during makeRealRequest

I'm debugging an issue whereby removing the host header causes a mismatch for signed requests (aws in this case) which includes the host header value in it's signing. I also looked into node-fetch, your upstream dependency, and found that it does not add a host header. However, according to Mozilla

A Host header must be sent in all HTTP/1.1 requests and serves may respond with 400 for any request that lacks a host header

(source)

I think the right thing to do is maybe to overwrite the host header if it is not set to be the options.host: https://github.com/ijpiantanida/talkback/pull/51

I can't think of a reason that we wouldn't want a host header in this request under any circumstances. WDYT?

ijpiantanida commented 3 years ago

node-fetch should be adding the host header.

I locally aliased mystrangedomain.com to localhost. image

What host option are you giving to talkback?

brandonc commented 3 years ago

@ijpiantanida Thanks for looking into this so quickly. You are right! I tested from the fetch side but didn't consider that node http is actually setting the host. Once I checked from the server side as you did I saw the host there.

Theoretically, deleting the host header should work! I'm not sure why it does not but I will debug some more.

brandonc commented 3 years ago

@ijpiantanida I must have made a mistake with a local modified version of talkback. deleting the host header works fine :grimacing: thank you, again.