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

Wed Jul 24 23:46:17 CEST 2013

Dear Davean,

I hope that I correctly interpret your mails. I guess you are talking about connection information available at the proxy when the user makes a connection. And usually this information is passed on to the backends using special headers such as x-forwarded-for and x-forwarded-proto. Right?

Isn't this information readily available using the requestHeaders function which well, should return those headers?

Furthermore I would think that the application in question would be responsible to interpret the available information correctly (this would be the framework on top of e.g. warp I guess).

The framework should then provide measures to correctly generate urls/links based on this information…as in fact done by various frameworks.

best regards,

Rico Moorman

On Jul 24, 2013, at 12:59 PM, davean <davean at xkcd.com> wrote:

> Completely not what I was saying.
> 
> "what IP they connected to, what port, on what interface, and even what ciphers were used ideally."
> 
> None of that is information the user could ever pass to the application except in the truly trivial cases. They're inherently features of each connection separately. If it isn't passed in the Wai Request it can't be (reasonably) discovered.
> 
> If some thing is going to try to derive for the user the pre-proxy IP based the connection information it should be a library that does such preferably or alternatively a middleware component, never the webserver. Furthermore WAI should contain sufficient information in the Request object to do this and more.
> 
> -davean
> 
> 
> On Wed, Jul 24, 2013 at 6:13 AM, Michael Snoyman <michael at snoyman.com> wrote:
> I think Greg and davean are saying something similar here. If I may paraphrase (please correct me if I'm wrong): some information may not be derivable by the WAI handler (e.g. Warp) itself, but with a little bit of help from the user, that information could be included in the WAI standard.
> 
> If that's what you're getting at, I disagree. This would essentially mean we require users to provide information to Warp, so that Warp can provide that information to user applications. Warp (or any other handler) is just a dumb transport mechanism then. And since we can't rely on that information being present, we'd wrap it up with Maybe values, and therefore end up losing type safety.
> 
> The prime example of all this is application root. I still strongly believe that Yesod did this the right way: if the user needs to provide the information, then ask the user to provide the information to the application itself, and the WAI handler needn't know anything about it.
> 
> Is there some kind of data that the WAI handler could do a better job of passing onto the application than the user can do?
> 
> 
> On Tue, Jul 23, 2013 at 11:58 PM, Greg Weber <greg at gregweber.info> wrote:
> In Rack most of these things are known. In some cases this requires users to configure the proxy to send headers.
> 
> One solution would be having the user state what values are being depended on and having Warp fail on startup with an error message if it can't collect them.
> It is possible to expect some of these values to not change (and require a reboot of warp when they do) and have them be part of Warp rather than WAI.
> 
> But just wrapping these values in a Maybe could be another approach.
> 
> 
> On Tue, Jul 23, 2013 at 1:13 PM, Michael Snoyman <michael at snoyman.com> wrote:
> The reason we'd be removing those is that there *still* isn't any way to know this. If Warp is sitting behind a reverse proxy (which is virtually always the case, whether Amazon ELB, Nginx, Keter, or something else) there's no way to know what the actual server name, server port, or scheme are.
> 
> 
> On Tue, Jul 23, 2013 at 6:37 PM, Federico Mastellone <fmaste at gmail.com> wrote:
> Hi,
> 
> Without isSecure and serverPort, will Applications be able to handle requests to different ports and HTTP or HTTPS in different ways? I won't be able to know if the login is made over HTTP and redirect to HTTPS with any Wai server.  
> 
> On 23/07/2013, at 07:04, Michael Snoyman <michael at snoyman.com> wrote:
> 
>> Some of you may have seen the brief interchange between Kazu and myself regarding ResourceT in WAI. Let me give a very brief synopsis of the situation:
>> In order to allow WAI applications to acquire scarce resources like file handles in an exception-safe way, WAI actions all live in a `ResourceT IO` monad, instead of just `IO`.
>> Kazu has mentioned to me in the past that, based on his profiling, monadic bind for ResourceT may currently be a bottleneck in WAI.
>> I made an experimental change to WAI so that, instead of actions living in `ResourceT IO`, the WAI Request value contains a ResourceT InternalState value, which can be used to accomplish the exact same thing as living in ResourceT (see [1]).
>> Kazu checked out the performance difference of this new branch, and it allows for some better optimizations.
>> If this was purely a performance optimization, I would probably just optimize Warp and not bother changing WAI. However, I think that this change makes WAI itself better as well, and therefore am in favor of making this as a breaking change, releasing it as WAI 2.0[2]. Firstly, are there any objections to this move?
>> 
>> So as long as we're making a breaking change, the question arises: what other changes should we be making to WAI? I know Kazu had mentioned adding fields to avoid the need for lookups, can you clarify that request a bit? Here are some other changes I can think of:
>> Remove the deprecated isSecure field from the Request data type.
>> Remove the misleading fields serverName and serverPort fields as well.
>> Possibly: hide the Request constructor so that new fields can be added without breaking backwards compatibility.
>> If anyone else has some ideas, please bring them up.
>> 
>> [1] http://haddocks.fpcomplete.com/fp/7.4.2/20130704-120/resourcet/Control-Monad-Trans-Resource.html#g:10
>> [2] For the Yesod community: the change is minor enough that Yesod 1.2 can have some conditional compilation to support both the current WAI 1.4 and WAI 2.0, so this shouldn't affect most Yesod users at all.
>> _______________________________________________
>> web-devel mailing list
>> web-devel at haskell.org
>> http://www.haskell.org/mailman/listinfo/web-devel
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups "Yesod Web Framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to yesodweb+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups "Yesod Web Framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to yesodweb+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
> 
> 
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
> 
> 
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20130724/b50dfe2e/attachment.htm>