# "Return" path in a node

**URL:** https://discourse.nodered.org/t/return-path-in-a-node/89630
**Category:** Developing Nodes
**Created:** [19 July 2024 13:27 UTC](https://discourse.nodered.org/t/return-path-in-a-node/89630 "2024-07-19T13:27:40Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![triblondon](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/triblondon/32/92917_2.png) [@triblondon](https://discourse.nodered.org/u/triblondon)
#### Post date: [19 July 2024 13:27 UTC](https://discourse.nodered.org/t/return-path-in-a-node/89630/1 "2024-07-19T13:27:40Z")

</div>

I'm trying to make a set of nodes for working with an HTTP proxy, allowing the proxy to be configured to perform various operations on requests that come through it all in a low-code way. My question is, **can I have a node that operates on the outbound AND return path of the request, with other nodes in between?**

Imagine I have an "authentication" node that verifies the client's identity on the request, and then also sets a cookie on the response.

```plaintext
HTTP in -> Auth -> Backend fetch -> Auth (again) -> HTTP response

```

Is it possible for a flow to pass through the same node twice? I guess by having a node with two inputs and two outputs?

Or should I do this with multiple nodes - a request phase and response phase?

How would you co-ordinate / maintain state between the request and response phase? Would you do that by carrying state in the message and hoping it is not wiped out by any nodes that process the message in between?

---

<div class="post-metadata">

### Author: ![marcus-j-davies](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/marcus-j-davies/32/103435_2.png) [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)
#### Post date: [19 July 2024 13:44 UTC](https://discourse.nodered.org/t/return-path-in-a-node/89630/2 "2024-07-19T13:44:12Z")

</div>

Hi @triblondon - Welcome to forums!

A node can only ever have 1 input.

But… there are 2 ways to accomplish this.

1. Using a link-call node setup, so different parts of the flow call the same auth operation block.

2. using a combination of switch nodes and message tagging, and direct traffic based on the current tag value, you can swing back around the auth operation and it will output to a different pin on switch nodes, based on the current tag, the topic property will can be used for this

Link call nodes, sounds like a perfect fit, if I understand your requirements

---

<div class="post-metadata">

### Author: ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [19 July 2024 14:06 UTC](https://discourse.nodered.org/t/return-path-in-a-node/89630/3 "2024-07-19T14:06:30Z")

</div>

> [@triblondon](#):
>
> How would you co-ordinate / maintain state between the request and response phase? Would you do that by carrying state in the message and hoping it is not wiped out by any nodes that process the message in between?

Yes. Not so much a 'hope' rather an 'expect'. If any do lose the response data there are ways to work around that, after submitting an issue against the node.

---

<div class="post-metadata">

### Author: ![triblondon](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/triblondon/32/92917_2.png) [@triblondon](https://discourse.nodered.org/u/triblondon)
#### Post date: [22 July 2024 08:06 UTC](https://discourse.nodered.org/t/return-path-in-a-node/89630/4 "2024-07-22T08:06:05Z")

</div>

Thank you both, much appreciated!

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)
#### Post date: [5 August 2024 08:07 UTC](https://discourse.nodered.org/t/return-path-in-a-node/89630/5 "2024-08-05T08:07:00Z")

</div>

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
