Closed ryfow closed 3 years ago
This is the wrong place for it. The behaviour of core functions shouldn't be changed; rather, we should add in new functions, or new middleware to accommodate. For example, a ring.middleware.proxy-headers/wrap-forwarded-scheme
function might be a better fit.
Ahh, thanks. Looks like it's already handled but ring-defaults doesn't take advantage of it. I can manage in my own codebase with configuration but do you think site-defaults
and api-defaults
should set :proxy
to true
?
Ahh, thanks. Looks like it's already handled but ring-defaults doesn't take advantage of it.
You may have misunderstood my comment. I'm saying that a function like wrap-forwarded-scheme
would be a good addition, not that it already exists.
do you think
site-defaults
andapi-defaults
should set:proxy
totrue
?
I don't see any reason why they should be.
I think I understand you, but it does already exist in ring.middleware.ssl/wrap-forwarded-scheme
.
The reason changing the defaults makes some sense to me is that depending on STS, Chrome & Firefox treat redirects to http://
differently so devs may run into weird bugs if they only use Chrome. I don't feel strongly about it though, so close this if you want to end the conversation.
Thanks again, Ryan
I think I understand you, but it does already exist in
ring.middleware.ssl/wrap-forwarded-scheme
.
Ah, so it does. I had completely forgotten about that. Well done finding it.
The reason changing the defaults makes some sense to me is that depending on STS, Chrome & Firefox treat redirects to
http://
differently so devs may run into weird bugs if they only use Chrome.
I'd rather make it explicit, for three reasons:
fair enough
We're having problems with
wrap-absolute-redirects
sending the browser tohttp:
and the underlying problem is thatring.util.request/request-url
doesn't takex-forwarded-proto
into account. I'm happy to move the change into wrap-absolute-redirects or make this fn multi-arity if you think this is too heavy handed.