search

fukamachi / clack

Web server abstraction layer for Common Lisp
MIT License
1.04k stars 86 forks source link

Added a test to check if the server is respecting X-Forwarded-Proto header to set the scheme in the env #156

Closed svetlyak40wt closed 5 years ago

svetlyak40wt commented 5 years ago

The X-Forwarded-Proto header is a de-facto standard header for identifying the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.

More details on https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto

Pull https://github.com/fukamachi/woo/pull/79 depends on a test from this pull.

fukamachi commented 5 years ago

Since Clack aims to be a thin HTTP abstraction layer, I'm not sure the special logic should be implemented in Clack. Clack's ENV represents HTTP parameters like Apache's or nginx's, so it could be considered if those web servers' REQUEST_SCHEME is affected by the HTTP header X-Forward-Proto. (I don't have enough time to google for now, though)

fukamachi commented 5 years ago

Additinally, it's troublesome to add such a logic to every Clack handlers.

Lack.Request may have a function to tell whether the request is over SSL or not, like request-ssl-p, if it works for your purpose.

svetlyak40wt commented 5 years ago

The problem I'm trying to solve is that request-uri-scheme returns wrong scheme – http, when my common lisp process is behind a reverse proxy. request-host returns correct data but request-uri-scheme isn't.

I'm using this data to build a full site's url to use it as a webhook address or in a emails.

If you think, it is wrong to fix this in the Lack, I'll accept it and will fix this behaviour at the Weblock code, here:

https://github.com/40ants/weblocks/blob/5643d2faa627373974f5a8cf3dc3c4c901fefce4/src/request.lisp#L51-L62

P.S. – not sure if request-ssl-p is needed.

svetlyak40wt commented 5 years ago

I've made this feature in the Weblocks:

https://github.com/40ants/weblocks/pull/22