[FEAT]: Support transparent redirect when requested URI contains double slash

[RaidMax]

Feature Description

I'm using a reverse proxy url for Synology DSM and noticed that some of the requests to the host are using a double forward slash in the requested URI.

Example:

When Cosmos receives this request it sends back a 301 redirect with a revised url (only a single /).
However, the client app doesn't expect this response, and doesn't follow the redirect, which ends up breaking some downstream functionality.

When this request is received directly by the host, it returns an expected 200, so it's Comos' behavior that is throwing a wrench in things.

I would like either a default behavior or an option of enabling a behavior that would transparently redirect requests that have double slashes (//) to the intended location without invoking a 301 redirect.

[azukaar]

This is an invalid URL that's why
I did not add the logic of fixing it, it's an internal Go mechanism
Synology needs to fix it on their end

[RaidMax]

This is an invalid URL that's why I did not add the logic of fixing it, it's an internal Go mechanism Synology needs to fix it on their end

Thanks for your response. I completely understand your position. However I have no idea on the feasibility of getting that changed in DSM or the timeline for that change to be made.

I’m not claiming this as a bug in cosmos, but just request for a flag that would support apps that may request malformed urls of this nature.

For comparison when routed through a traditional reverse proxy like nginx the request from the DSM client code receives the expected response without a 301 redirect.

I have setup a local development environment in which am able to compile and run comos with the intention of implementing this behavior. If you’d entertain the idea of incorporating it in a PR I can take a crack at. However I’m not familiar with go so I will need to do a little investigation on the best approach.

[Ayymoss]

This Synology fault is handled gracefully on nginx without any special configuration. I understand the reluctance to provide a workaround here.

I've also created a bug report via Synology's ticket, but it would be nice to resolve this sooner than Synology's devs to at least marry up functionality with Nginx.

Will update this comment with the status from Synology's ticket once I know more.

---

Response from Synology: