redirect by location in responseheader

[cedricbieder]

Bug Description

Hello, I am getting an annoying bevahior by one of my client targets.
I want to tunnel a https page:

The page is running on port 82, by my frpc and frps .ini I forward that page to subdomain.mydomain:8082.
I get the login in page of the targt. But after I login the page always jump to subdomain.mydomain:82.
I could observe that before that redirect I get a location: subdomain.mydomain:82. in the response header by the page.

I tried something like host_header_rewrite, but that seems to have no impact at all.

So my question. Is there an opportunity I can block this redirect? or I can change the response header (on frpc or frps)?
Or do you think I have to fix this on the target webpage?

Thank you for your support and project.

frpc Version

0.45

frps Version

0.45

System Architecture

linux/amd64

Configurations

[common]
server_addr = myDomain
server_port = 8082
authentication_method = token
token =
log_level = trace

user = no_test2

[23]
type = https
plugin = https2https
subdomain = e7b65b443b14cb26a76f0660
plugin_local_addr = targetHost:82
plugin_crt_path = <path_to_cert>
plugin_key_path = <path_to_cert>

Logs

No response

Steps to reproduce

...
Tbh I dont know how to reproduce this bug, it happens only at this one webpage.

Affected area

• Docs
• Installation
• Performance and Scalability
• Security
• User Experience
• Test and Release
• Developer Infrastructure
• Client Plugin
• Server Plugin
• Extensions
• Others

[fatedier]

You can change your webpage logic to generate the location header.

[cedricbieder]

Ok thank you, but what if I can not change the webpage header (e.g., it is not my webpage)?

[penguine]

You can change your webpage logic to generate the location header.

he could - similar to:
plugin_host_header_rewrite
change the location?
see: https2https.go New HTTPS2HTTPSPlugin

he should still be able to set the port too, right?
he would therefore have to expand the plugin_host_header_rewrite

[penguine]

I found this hint:
golang/go#28168
the problem seems to be fixed. but could still have something to do with it.
I have found another workaround (without the fix). now you have to test it.

                // because of github.com\golang\go\issues\28168, the
		// upstream won't receive the expected Host header unless this
		// is forced in the Director func here
		chainDirector(p.reverseProxy, func(request *http.Request) {
			// send original host along for the upstream
			// to know it's being proxied under a different Host
			// (for redirects and other stuff that depends on this)
			request.Header.Set("X-Forwarded-Host", request.Host)
			request.Header.Set("Forwarded", fmt.Sprintf("host=%s", request.Host))
			// override the Host with the target
			request.Host = request.URL.Host
		})

[fatedier]

he could - similar to:
plugin_host_header_rewrite

Try this config.

[cedricbieder]

@fatedier , thank you. I tried this already, but it just changes the host and not the port. He takes the port form "plugin_local_addr" instead. I could not finde where I can access the code to fix that or why he takes the port from there.

[penguine]

a configuration now works with:

plugin_host_header_rewrite = <frps-host>
plugin_header_X-Forwarded-Host = <frps-host>:<frps-port>

but this does not solve all problems. i also have like: @cedricbieder
a page where, the port in the location is set wrong. target server is an IIS. in the reponse header the location can not be set correctly. the URL can be changed, but the port is then always the port of the target computer and not that of the frps ... any further ideas?

[github-actions]

Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.