Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Can we make reverse proxy response available in templates #4420

Open
byoungdale opened this issue Nov 15, 2021 · 9 comments
Open

Can we make reverse proxy response available in templates #4420

byoungdale opened this issue Nov 15, 2021 · 9 comments
Assignees
@mholt @francislavoie
Labels
feature ⚙️ New feature or request

Comments

@byoungdale
Copy link

This is in response to my question here on the community forum.

Can we add a feature where the response to a reverse proxy can be made available to or passed as argument(s) to templates?

:9000

reverse_proxy 127.0.0.1:3000 {
              handle_response {
                              templates
                              try_files posts.html
                              file_server
              }
}

And if the response from the 127.0.0.1:3000 application is:

[
  {
    "id": 1,
    "title": "Post 1"
  },
  {
    "id": 2,
    "title": "Post 2"
  },
  {
    "id": 3,
    "title": "Post 4"
  },
]

Being able to do something like this:

<!DOCTYPE html>
<html>
	<body>
		<main>
			<div class="post-container">
                                 {{range $field, $val := .Res.Body}}
                                         	<p id={{$val.id}}>{{$val.title}}</p>
                                  {{end}}
			</div>
		</main>
	</body>
</html>
@francislavoie
Copy link
Member

francislavoie commented Nov 15, 2021 •
edited
Loading

Hmm. I think you'd be better off by responding with HTML that has JS fetch() calls to get the JSON, and render that however you need with JS.

Or, write a separate backend endpoint that renders HTML from the the JSON with an actual programming language.

There's a bunch of pieces in play here that make this tricky to implement, and I'm afraid it'll add undue complexity to the system:

  • Response may be huge, making it available in templates would mean reading it all and buffering it into memory
  • Making the data available in templates could require some complex pipework
  • The response may not necessarily be JSON, decoding it to make it available in an map, and probably not handle other kinds of responses seems weird

@francislavoie francislavoie added the feature ⚙️ New feature or request label Nov 15, 2021
@mholt
Copy link
Member

mholt commented Nov 15, 2021

Yeah, this'll definitely require buffering the response. Maybe if it was explicitly enabled in config (up to a max size, I dunno?) that would be one easy way to do it. For example, "Enabling this option always reads the response from the backend up to a certain size and then sets these placeholders/variables, etc."

@francislavoie
Copy link
Member

FYI, this should be closer to being possible to implement now that we have a copy_response handler in handle_response routes (as of v2.5.0-beta.1).

Parsing the response is a whole other thing though, and likely best left to plugins once #4568 is done as well.

@mindon
Copy link

mindon commented Jul 1, 2022

it seems working under v2.5.1, but how to turn it off?

@francislavoie
Copy link
Member

@mindon you'll need to elaborate. What's your config? What behaviour are you seeing? What does it look like when you make a request with curl -v?

@mindon
Copy link

mindon commented Jul 4, 2022 •
edited
Loading

@mindon you'll need to elaborate. What's your config? What behaviour are you seeing? What does it look like when you make a request with curl -v?

curl -v works fine, the issue pattern is encode zstd gzip → reverse_proxy → templates

remove encode zstd gzip from target server or the templates from current server deliminates the 500 error

#4819

here's a simple config

{
  debug
	auto_https off
}

:8081 {
  encode zstd gzip
  root * ./hello
  route /world/* {
    uri strip_prefix /world
    header X-Real-IP {http.request.remote}
    reverse_proxy 127.0.0.1:8080
  }
  file_server
  templates
}

:8080 {
  encode zstd gzip
  root * ./world
  file_server
  templates
}

@mindon
Copy link

mindon commented Jul 6, 2022

@francislavoie a simple case is proxy target output something like "{{}}", then caddy app with templates will surely 500 error

@francislavoie
Copy link
Member

francislavoie commented Jul 6, 2022 •
edited
Loading

That seems off-topic from what this issue is about @mindon.

The feature request here is about being able to write the proxy response from within a template, with handle_response. Your config doesn't do that.

mholt added a commit that referenced this issue Jul 7, 2022
@mholt
templates: Access to proxy response (closes #4420)
577f8ba 
Also sorted the func map just for kicks.
@mholt
Copy link
Member

mholt commented Jul 7, 2022

@byoungdale Please see #4871 where I've implemented this functionality. It's a little rough around the edges still, but it should work.

If you want to parse JSON, simply use the fromJSON or mustFromJSON function: https://masterminds.github.io/sprig/defaults.html#fromjson-mustfromjson

@mholt mholt added this to the v2.6.0 milestone Jul 7, 2022
@mholt mholt modified the milestones: v2.6.0, v2.6.1, v2.6.2 Sep 16, 2022
@mholt mholt modified the milestones: v2.6.2, v2.6.3 Sep 29, 2022
@mholt mholt removed this from the v2.6.3 milestone Nov 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mholt mholt

@francislavoie francislavoie

Labels
feature ⚙️ New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@mindon @mholt @francislavoie @byoungdale