Re: [web-devel] [Yesod] Re: Next version of WAI: cleaning house

Michael, I agree that you are theoretically correct not to include extra info for example about approot. On the other hand, when someone comes from using Rails we have to explain to them this theory about why they have to manually enter approot and can't tell if their app is over https, but they will still scratch their head since in Rails that information was always readily available. So I am wondering if there is a middle ground to be found where being theoretically correct doesn't mean zero programmer convenience. But perhaps this has nothing to do with the WAI standard and should be handled by middleware? On Wed, Jul 24, 2013 at 5:23 AM, Michael Snoyman wrote:

On Wed, Jul 24, 2013 at 3:08 PM, Kazu Yamamoto wrote:

...

Michael,

...

I'm definitely not talking about removing the peer information. Request has a remoteHost field which is of type SockAddr, and therefore provides both remote IP address and port number (the latter, as you mention, being mostly useless).

Please understand that I'm not opposing your opinion. I'm just trying to interpret user's opinions.

I appreciate the input, I just wanted to clarify my proposal.

...

...

I'm not sure what you mean by telling if communication is encrypted using the headers + IP address, can you clarify?

Suppose a Yesod application receives X-Forwarded-For:.

A bad client can insert X-Forwarded-For:. But if an IP address is provided and the application knows the IP address of the proxy, the application can tell whether or not the IP address can be trusted.

I'm not sure that there is a standard header field to tell HTTPS. But if the proxy and the application shares such field: - The application can truct the field according peer's IP address - The application can tell the outside HTTP is encrypted

Correct me if I misunderstand.

I'd never considered checking the IP address of the proxy. When I've used X-Forwarded-For, I've always made sure to set up a firewall to ensure the *only* connections come from the reverse proxy, and then x-forwarded-for can be trusted.

As far as determining secure/insecure, it seems like Amazon's ELB sets x-forwarded-proto[1]. Not sure if that's a well accepted standard, but it seems useful.

Michael

[1] http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/Termin...

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel