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

Thu Jul 25 00:55:46 CEST 2013

No, assume there *is no proxy*. All I'm talking about is what the webserver
its self sees. Anything to do with proxies or other infrastructure really
isn't WAI's place.

-davean

On Wed, Jul 24, 2013 at 5:46 PM, Rico Moorman <rico.moorman at gmail.com>wrote:

> 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/bf79421e/attachment.htm>