Originally assigned to: @oschwartz10612 on GitHub.
Describe the Bug
I use a resource that needs a custom header to function. Whenever I go to edit authentication, general, or rules within the same resource, the custom header value I have gets cleared, requiring me to re-enter it and save again.
Environment
OS Type & Version: Ubuntu 22.04
Pangolin Version: 1.12.2 (using local only unmanaged)
Gerbil Version: 1.2.2
Traefik Version: 1.18
Newt Version: 1.6.0
Olm Version: (if applicable)
To Reproduce
Open an existing resource and add any value to the custom header on the proxy page, then save.
Close the resource, refresh the page, and reopen the resource.
Edit the name of the resource, then click save.
Go to the proxy page, the value in the custom headers will be gone.
(I am happy to share a video privately)
Expected Behavior
The custom header value remains and is not blanked out.
Originally created by @andrewixl on GitHub (Nov 18, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1885
Originally assigned to: @oschwartz10612 on GitHub.
### Describe the Bug
I use a resource that needs a custom header to function. Whenever I go to edit authentication, general, or rules within the same resource, the custom header value I have gets cleared, requiring me to re-enter it and save again.
### Environment
- OS Type & Version: Ubuntu 22.04
- Pangolin Version: 1.12.2 (using local only unmanaged)
- Gerbil Version: 1.2.2
- Traefik Version: 1.18
- Newt Version: 1.6.0
- Olm Version: (if applicable)
### To Reproduce
1. Open an existing resource and add any value to the custom header on the proxy page, then save.
2. Close the resource, refresh the page, and reopen the resource.
3. Edit the name of the resource, then click save.
4. Go to the proxy page, the value in the custom headers will be gone.
(I am happy to share a video privately)
### Expected Behavior
The custom header value remains and is not blanked out.
GiteaMirror
added the bug label 2026-04-16 08:59:17 -05:00
adding to this issue as it's likely related:
the same issue happens for the expected response codes and headers in the health check.
so far i've been able to get it to save once, but all the other times it is also cleared
<!-- gh-comment-id:3568404505 -->
@thutex commented on GitHub (Nov 23, 2025):
adding to this issue as it's likely related:
the same issue happens for the expected response codes and headers in the health check.
so far i've been able to get it to save once, but all the other times it is also cleared
@PavanendraBaahubali commented on GitHub (Nov 25, 2025):
Hey @oschwartz10612, is this issue already resolved, or is it still available to work on?
<!-- gh-comment-id:3575188847 -->
@PavanendraBaahubali commented on GitHub (Nov 25, 2025):
Hey @oschwartz10612, is this issue already resolved, or is it still available to work on?
@oschwartz10612 commented on GitHub (Nov 25, 2025):
@PavanendraBaahubali you could open a PR for a fis, that would be awesome!
<!-- gh-comment-id:3575921589 -->
@oschwartz10612 commented on GitHub (Nov 25, 2025):
@PavanendraBaahubali you could open a PR for a fis, that would be awesome!
@PavanendraBaahubali commented on GitHub (Nov 27, 2025):
I tried to reproduce the behavior on my machine, but everything worked correctly. The only time the custom headers don’t get saved is when the value isn’t formatted as:
Invalid (ignored and not included in the payload):
something
my-header
key value
If a line doesn’t contain a : separator, Pangolin won’t send that header in the update payload, which makes it look like the value disappeared.
Could you double-check whether the custom headers you entered follow the Header-Name: value format?
If you can share an example (even redacted), I can help verify.
<!-- gh-comment-id:3585359557 -->
@PavanendraBaahubali commented on GitHub (Nov 27, 2025):
I tried to reproduce the behavior on my machine, but everything worked correctly. The only time the custom headers don’t get saved is when the value isn’t formatted as:
```
Header-Name: value
```
For example:
* **Valid (saved correctly):**
```
X-Example-Header: example-value
X-Another-Header: another-value
```
* **Invalid (ignored and not included in the payload):**
```
something
my-header
key value
```
If a line doesn’t contain a `:` separator, Pangolin won’t send that header in the update payload, which makes it look like the value disappeared.
Could you double-check whether the custom headers you entered follow the `Header-Name: value` format?
If you can share an example (even redacted), I can help verify.
I tried to reproduce the behavior on my machine, but everything worked correctly
so have you:
saved the headers (yes, i'm saving in the right format - they do get ORIGINALLY saved
then went around and edited things like enabling a pin code on the resource and changing a rule (and saving ofcourse)
then going out of the resource
going back
et voila: headers empty
a workaround is to edit the rules, save them, go back to the proxy screen (where it is still filled in now), and save that again as well.
then the information is saved for both rules & headers.
but if you have the header saved from before and then reopen the resource, change a rule, save, and leave: the headers will be empty
and in the health check (which is what i noticed first) , the expected response codes sometimes dont seem to save,
and also don't seem to allow for 'codes' (plural), just 1 (tried spaces, comma, dash)
(i however did not want to open a new issue for this, as i'm assuming both issues are frontend related or related to how data is sent when being saved, like perhaps when changing a rule, only that is sent, but the backend then adds null for the headers for example as it was maybe expecting that info as well)
<!-- gh-comment-id:3585863311 -->
@thutex commented on GitHub (Nov 27, 2025):
> I tried to reproduce the behavior on my machine, but everything worked correctly
so have you:
- saved the headers (yes, i'm saving in the right format - they do get ORIGINALLY saved
- then went around and edited things like enabling a pin code on the resource and changing a rule (and saving ofcourse)
- then going out of the resource
- going back
- et voila: headers empty
a workaround is to edit the rules, save them, go back to the proxy screen (where it is still filled in now), and save that again as well.
then the information is saved for both rules & headers.
but if you have the header saved from before and then reopen the resource, change a rule, save, and leave: the headers will be empty
and in the health check (which is what i noticed first) , the expected response codes sometimes dont seem to save,
and also don't seem to allow for 'codes' (plural), just 1 (tried spaces, comma, dash)
(i however did not want to open a new issue for this, as i'm assuming both issues are frontend related or related to how data is sent when being saved, like perhaps when changing a rule, only that is sent, but the backend then adds null for the headers for example as it was maybe expecting that info as well)
@PavanendraBaahubali commented on GitHub (Nov 28, 2025):
Hey @oschwartz10612, please take a look at my PR when you can. Thanks!
<!-- gh-comment-id:3589416677 -->
@PavanendraBaahubali commented on GitHub (Nov 28, 2025):
Hey @oschwartz10612, please take a look at my PR when you can. Thanks!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @andrewixl on GitHub (Nov 18, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1885
Originally assigned to: @oschwartz10612 on GitHub.
Describe the Bug
I use a resource that needs a custom header to function. Whenever I go to edit authentication, general, or rules within the same resource, the custom header value I have gets cleared, requiring me to re-enter it and save again.
Environment
To Reproduce
(I am happy to share a video privately)
Expected Behavior
The custom header value remains and is not blanked out.
@thutex commented on GitHub (Nov 23, 2025):
adding to this issue as it's likely related:
the same issue happens for the expected response codes and headers in the health check.
so far i've been able to get it to save once, but all the other times it is also cleared
@PavanendraBaahubali commented on GitHub (Nov 25, 2025):
Hey @oschwartz10612, is this issue already resolved, or is it still available to work on?
@oschwartz10612 commented on GitHub (Nov 25, 2025):
@PavanendraBaahubali you could open a PR for a fis, that would be awesome!
@PavanendraBaahubali commented on GitHub (Nov 27, 2025):
I tried to reproduce the behavior on my machine, but everything worked correctly. The only time the custom headers don’t get saved is when the value isn’t formatted as:
For example:
Valid (saved correctly):
Invalid (ignored and not included in the payload):
If a line doesn’t contain a
:separator, Pangolin won’t send that header in the update payload, which makes it look like the value disappeared.Could you double-check whether the custom headers you entered follow the
Header-Name: valueformat?If you can share an example (even redacted), I can help verify.
@thutex commented on GitHub (Nov 27, 2025):
so have you:
a workaround is to edit the rules, save them, go back to the proxy screen (where it is still filled in now), and save that again as well.
then the information is saved for both rules & headers.
but if you have the header saved from before and then reopen the resource, change a rule, save, and leave: the headers will be empty
and in the health check (which is what i noticed first) , the expected response codes sometimes dont seem to save,
and also don't seem to allow for 'codes' (plural), just 1 (tried spaces, comma, dash)
(i however did not want to open a new issue for this, as i'm assuming both issues are frontend related or related to how data is sent when being saved, like perhaps when changing a rule, only that is sent, but the backend then adds null for the headers for example as it was maybe expecting that info as well)
@PavanendraBaahubali commented on GitHub (Nov 28, 2025):
Hey @oschwartz10612, please take a look at my PR when you can. Thanks!
@miloschwartz commented on GitHub (Dec 3, 2025):
Thanks. Closing this since it will be fixed in the next release :D